Opening

They said we were family. Funny how families work—I was there for every 3 AM emergency, every impossible deadline, every “quick pivot.” I was the reliable one, the top contributor, the person who “really gets it.” Then I left. Guess how long that family remembered me? About as long as it took to post my job listing. Spoiler: it was already written.

Here’s what nobody tells you about startup life: everyone is replaceable, including you. Especially you. But here’s the part they really don’t mention—your time isn’t replaceable. Those weekends you gave up? Gone. That relationship that withered because you were always “in the middle of something”? Can’t get that back. The health problems from stress and sleep deprivation? Yeah, those stick around longer than your equity options.

This isn’t a burnout story. I’m not broken. I’m on the market, I’m still shipping code, I’m still solving hard problems. But I’m also done pretending the emperor is wearing clothes. Consider this your field guide to the realities they won’t put in the job description.

Disclaimer

These stories come from my 25+ year career. Multiple companies. Multiple startups. Multiple experiences that blur together into patterns.

So if you see yourself somewhere in here, it might be you. Or it might not. It might be the person at the desk next to you. Or three companies ago. Or the pattern I’ve seen repeated across a dozen different teams with different names but identical dysfunction.

What I describe is the trend, not the exception. These aren’t isolated incidents—they’re the recurring themes of startup culture as I’ve lived it.

Your mileage may vary. But probably not as much as you’d hope.

Welcome to the Family

I got into startups because I’m wired for hard problems. Give me a gnarly technical challenge, a chance to learn something new, throw me into the R&D deep end—that’s my happy place. That’s what they sold me on, and I bought it willingly.

The pitch was intoxicating: we’re building something important (compliance and security—real problems, technical depth), small team, big impact, and oh, the learning opportunities. You’ll grow faster here than anywhere else. They weren’t wrong about that last part, just not in the way they meant it.

The “family” thing started immediately. Team dinners. Bonding events. The CEO and managers would take us out, make toasts about how “you ARE this company.” Not “you work for” this company—you ARE it. Feel the difference? One’s a job. The other’s an identity. An obligation. A guilt mechanism.

And for a while, it felt real. We were in it together. Small team, big mission. The camaraderie was genuine—at least between us engineers. We had each other’s backs because we had to. We were the ones who’d be up at midnight when things broke.

When Normal Becomes Insane (And You Don’t Notice)

The slow boil started with “just this once.”

The CEO promised a customer a solution—without consulting engineering, naturally—and suddenly we’re monitoring features in production that weren’t actually… done. You know, that minor detail. Weekend work wasn’t officially required, but when the boss promises something you haven’t built yet, what are you going to do? Let it crash and burn? You care about your work, about the product, about not looking like the bottleneck. So you work the weekend.

“Just this once” became a pattern so gradually I didn’t see it happening.

Then came the midnight calls. System failures because code was rushed to production to meet promises made by the business side. And guess who got to investigate and fix it? Not the CEO who made the promise. Not the sales team who closed the deal. The engineer who’d been saying “this isn’t ready” gets to debug it at 2 AM while they sleep soundly, probably dreaming of their next unrealistic commitment.

You tell yourself it’s temporary. Once we stabilize. Once we hire more people. Once we hit product-market fit. Once, once, once. It’s like waiting for Godot, except Godot is reasonable working hours and he’s not coming.

The Role That Ate My Life

I was hired as an engineer. That’s what my offer letter said. That’s what I thought I was signing up for.

Within months, I was:

• Engineering manager (because we’re hiring now, and someone needs to manage them)
• Recruiter (your network is valuable! can you refer people?)
• Architect (someone needs to make these technical decisions)
• DevOps engineer on top of our actual DevOps engineer (because for quick MVPs, I had to do it myself to save time—the irony of “saving time” by doubling my workload was not lost on me)
• Customer support (it’s a technical issue, you need to talk to them)
• Integration specialist (here’s a PDF with minimal documentation, make it work)
• Firefighter-in-chief (24/7, unofficial but understood)

Each hat came with “just temporarily” or “until we hire for this” or my personal favorite: “you’re so good at this.”

The reward for being good at something in a startup? Doing that thing forever, plus three more things, for the same salary.

We had a DevOps person. A good one. But when you need an MVP yesterday and going through proper channels takes time, you just… do it yourself. ECS cluster? I’ll spin it up. Lambda functions? Sure, add it to Tuesday’s tasks. Azure Container Apps? Why not, I was running out of hobbies anyway.

“Saving time” is startup code for “creating a parallel shadow infrastructure that only you understand and will definitely break at the worst possible moment.”

The Golden Carrot (That Never Quite Materializes)

“We’re turning into a multibillion-dollar company and you’ll get your cut.”

They’d throw around numbers that made your eyes widen. We’re making one million in revenue. Then two million. Then four million. The growth! The trajectory! The geometric progression!

Except—and here’s where my Greek heritage serves me well—it’s not a γεωμετρική πρόοδος (geometrical progression). Revenue growth doesn’t work perpetually like that. Going from 1 to 2 million is not the same as going from 100 to 200 million. The math they sold wasn’t the math that mattered.

Meanwhile, I was being paid below market rate because… well, because I accepted it. Because they painted a picture of a future so bright I’d need sunglasses. Because “we’re investing everything back into growth.” Because “once we close the next round.” Because, because, because.

But I believed. For longer than I should have. Because they’d told me I was family.

Family doesn’t abandon you. Family values your sacrifice. Family has your back.

Right?

Spoiler alert: I was thinking of the wrong kind of family. This was more Godfather than Full House. And I wasn’t the Don—I was the guy they sent to “take care of things.”

The Cast of Characters (Or: The Startup Zoo)

The Code Cowboys (Or: Why We Can’t Have Nice Things)

Let me tell you about the people who made my midnight debugging sessions inevitable.

Not one person—that would be too simple. It was a rotating cast of characters united by a common philosophy: “Testing is for people who don’t believe in their code.”

QA processes? Those came later. Much later. After enough production fires that even management noticed. In the early days, code went from someone’s laptop to production with the rigorous validation process of “does it compile?”

Some wrote code without testing because they genuinely didn’t know better. Others had such deep technical knowledge that they’d architect beautiful, complex systems with one tiny flaw: change one thing here, and something breaks on the other side. And there was always—ALWAYS—a customer actively using that exact broken path.

Murphy’s Law has a special startup corollary: The feature that breaks will be the one the CEO just demoed to an investor.

The poorly designed initial architecture was like Greek tragedy—you could see the disaster coming from the first act, but you were powerless to stop it. Too much technical debt, too little time to refactor, too many promises already made about what the system could do.

And when it broke at 2 AM? Guess who got the call.

Not the person who wrote it. Not the person who approved it. Not the person who promised it.

Me. Because I was “good at firefighting.”

The Managers Who Managed to Miss the Point

Exhibit A: The Stack Modernization Saga

“We need to update the stack to modern Python.”

Finally, a reasonable request! This will be—

“But we can’t do it the rational way. No containers, no gradual migration, no separate environments. I want it upgraded inline. In production. While it’s running. And don’t break anything.”

Oh, is that all? Let me just violate the laws of physics and common sense while I’m at it.

For context, this is like asking a surgeon to replace your heart while you’re running a marathon. Sure, technically it’s the same body, but maybe—just maybe—we should stop and think about this?

“No, no, that would take too long. Just do it inline.”

Exhibit B: The Phantom Product Launch

“Let’s create a new product for compliance!”

Great! What are the requirements?

“Go check the competition and build something. I’ll tell you if I like it.”

Okay… and deadlines?

“ASAP.”

Management structure?

“Of course you’ll have a team!”

Wonderful! Experienced product managers who understand the domain?

“The best! A team of micromanagers who have zero idea about actual management but are always keen to discuss technical decisions they don’t understand!”

Nothing says “I trust your technical expertise” like someone who thinks Windows are exclusively house parts questioning your choice of database architecture.

“Why are we using this tech?” they’d ask, squinting at a Kubernetes diagram like it was modern art.

Because it solves the problem efficiently?

“But [competitor] uses [completely different tech for a completely different use case].”

Cool. Cool cool cool. Let me just rebuild everything because you saw a different thing once.

Exhibit C: The Build-It-And-They-Will-Come Approach

“The customer doesn’t know what they need. Get me something working and I’ll tell them this is what they need.”

This is management by entrepreneurial telepathy. We’re going to read minds, build products, and then convince customers they wanted this all along.

“The customer is waiting for this!” they’d say with urgency.

Then after weeks of frantic development, late nights, and cutting corners on code quality: crickets. No one used it. The “urgent” customer had moved on, or never existed, or wanted something completely different.

But hey, we shipped fast! Quality? Code processes? Testing? No thanks, we operate in our own universe where technical debt is someone else’s problem. Probably future-you’s problem. And future-you is also… you.

“You can build it!” they’d say with confidence that would be inspiring if it weren’t so disconnected from reality.

Yes, I CAN build it. The question is whether I SHOULD, and whether building it in three days instead of three weeks means we’ll spend three months fixing it later.

Spoiler: it does.

The Team I Was Holding Together

Here’s the thing about being the architect, the manager, and the therapist all at once: you’re not just building systems, you’re building people’s confidence in a system that’s actively trying to destroy that confidence.

I had engineers with no requirements, feeling pressure to build something they couldn’t envision. How do you write code for a product that exists only in a manager’s vague gestures and “you know, like [successful competitor] but different”?

So I became the holder of the big picture. I’d architect the vision, break it down, parcel out pieces that were actually buildable. Not too much information—that would overload them. Not too little—that would leave them paralyzed. Just enough to make progress while I fought the daily battle of “why does this need three months instead of three hours?”

“Three months? For a new product? Our competitor built theirs in a week!”

Did they, though? Or did they spend two years building the foundation, and you only saw the last feature launch?

I was translating between the land of “everything is possible and fast” and the reality of “software takes time and good software takes more time.” It’s exhausting being the only person in the room who understands that physics applies to code too.

People were stressed. Not because they weren’t capable—they were brilliant. But try being brilliant when someone keeps moving the goalposts, changing requirements mid-sprint, and asking “why isn’t it done yet?” about the thing they asked for yesterday.

I held them together. Gave them cover. Fought for reasonable timelines. Explained to management—repeatedly—why building something right takes longer than building something that barely works.

And when they came to me overwhelmed, doubting themselves, wondering if they were cut out for this? I had to be the one who said “you’re good at this, the system is broken.”

Which was true. But also exhausting when you’re questioning whether YOU’RE cut out for this.

The Culture Performance

“Forget processes and roadmap—you operate in your own universe. Build this and build it fast.”

This was said like it was empowering. Like I was being given freedom.

What it actually meant: “We don’t want to do the hard work of planning, so we’re going to call our chaos ‘agility’ and your stress ‘ownership.’”

There were no guard rails. No sustainable practices. Just urgency and conviction that speed was the only metric that mattered.

Quality? That’s future-you’s problem.
Code reviews? Slowing us down.
Documentation? We’ll do it later. (Later never came.)
Testing? We’ll test in production! (Via customer complaints!)

The culture was “move fast and fix things at midnight.”

And somehow, I became the person who both moved fast AND fixed things at midnight. Because I cared. Because I was good at it. Because someone had to.

That’s the trap. They find the people who care, who are competent, who will step up. And then they load everything onto those people until they break.

I didn’t break. But I came close enough to see what breaking looks like.

And the worst part? I enabled it by being too good at keeping everything running.

The Grind Economy (What You Actually Traded)

The Pandemic Trap (Or: How I Learned to Stop Worrying and Love My Laptop)

Here’s a dark irony for you: the pandemic saved me from burnout. For about five minutes.

When the world locked down and everyone was stuck at home with nothing to do, suddenly working 70-hour weeks felt… normal? Productive, even? While others were baking sourdough and learning TikTok dances, I had purpose. I had problems to solve. I had a reason to get out of bed.

The startup became my social life by default. Not by choice—by elimination of alternatives.

And management? Oh, they loved this. We were all home anyway! No commute means more working hours, right? The line between work and life didn’t blur—it evaporated. My laptop was always there. The problems were always there. The Slack messages were always there.

It felt like I was being saved from pandemic boredom. In reality, I was being slowly consumed, and the isolation made it invisible.

Then the pandemic ended.

People started going out again. Doing things. Living lives. And I was still… working. Except now it wasn’t “we’re all stuck home together”—it was “why aren’t you available on Saturday afternoon?”

Because normal people do things on Saturday afternoons. They see family. They have hobbies. They exist outside of their work identity.

I started sacrificing night sleep to get work done so I could have a few hours with family on weekends. Or I’d sacrifice weekend hours because that “urgent” issue couldn’t wait until Monday. The urgency was always justified in the moment. In retrospect? Most of it could have waited.

But I’d been trained. Conditioned. The pandemic year had normalized being always-on, and now I couldn’t find the off switch.

The Body Keeps Score (Even When You Ignore It)

“I’ll hit the gym later.”

Later became next week. Next week became next month. Next month became “I should really start going again.”

I’d skip gym sessions because I had something urgent to fix. Or because I was on a roll and didn’t want to stop my pace—momentum matters when you’re building, and breaking that flow felt wasteful. Better to skip the workout, right?

Some weight gain followed. Not dramatic, not worth worrying about. Just enough to notice my clothes fitting differently. Just enough to add to the mental load of “things I should fix but don’t have time for.”

Stress kicked in and sleep quality declined. Not the hours—I was still getting to bed. But the quality? Gone. My brain wouldn’t shut off. I’d lie there mentally debugging code, architecting solutions, replaying conversations with managers, preparing arguments for why we needed more time.

The worst part? The solutions would actually come to me at random times. I’d be watching a movie with family, supposedly relaxing, and suddenly a solution would flash in my mind. And I’d run to note it down. Because if I didn’t capture it immediately, it would haunt me. The movie was ruined anyway—I wasn’t present anymore, I was back in the code.

Work became part of my mindset at a neurological level. Not “work-life balance”—work-life fusion. Work-life hostile takeover.

My hobbies didn’t pause. They evaporated. I couldn’t tell you when I last did the things I used to do for fun. They just… stopped being part of my life, so gradually I didn’t notice until they were gone.

The Always-On Trap (And the People Who Exploited It)

Here’s how it worked: a few people knew the system end to end. We were the ones who could actually fix things when they broke. We were the encyclopedia of institutional knowledge.

So we were always the people to call and ask.

Email. Teams. Slack. All channels, always active. And we were always responding. Because we cared. Because we were professionals. Because the problem was real and someone needed help.

Management knew this. And they exploited it ruthlessly.

Even for low-priority things—stuff that could absolutely wait until Monday morning—they’d send a message. On Saturday evening. On Sunday morning. During dinner. Because they knew we’d reply.

Zero protection from them. Zero boundaries they’d respect.

We had this “run to help” mentality. It’s engineer DNA—someone has a problem, you want to solve it. They weaponized our helpfulness.

Promises were made. “We’ll set up a proper on-call rotation.” “We’ll implement shifts so no one is always on.” “We’ll protect your off-hours.”

These promises lasted exactly as long as it took for the next “emergency.” Then they were quietly forgotten. The idea was always: “I pay you the big bucks, you need to work.”

Except here’s the math they hoped I wouldn’t do:

If you count the off-hours I worked and normalize the payment accounting for them, I was making less per hour than a junior engineer working a standard 8-hour day.

The “big bucks” were an illusion. I was being paid for 40 hours and working 70. That’s not a good deal—that’s indentured servitude with better PR.

The Sweet-Talk Industrial Complex

“You’re our top contributor.”

“You’re irreplaceable.”

“You’re the glue that keeps everything together.”

“You’re the man who knows the system.”

“You’re the man who can build anything on any stack and integrate any system.”

“You’re the man who can deliver in days what takes others weeks.”

All of this was close to the truth, which made it effective. I did have the talent to understand complex systems quickly. I could see the big picture and architect solutions fast. I could build really fast—even before AI made fast building possible for everyone else, I was a “brain-vibe coder” on steroids.

And this talent was exploited. Heavily.

Every piece of sweet talk came with another responsibility. Every compliment was a setup for “and since you’re so good at this, could you also…”

The pattern was invisible until I looked back on it:

1. Identify the person who’s exceptionally capable
2. Tell them how exceptional they are
3. Give them more work because they’re exceptional
4. Repeat until they break or leave
5. Act surprised when they leave

I could do it, so I did it. And because I could do it, they kept asking. And because they kept asking, I kept doing it. And the cycle continued until I realized I wasn’t being valued—I was being mined.

Being called “irreplaceable” feels good right up until you realize it means you’re trapped. You can’t take vacation because who else can handle the production issues? You can’t push back on scope because you’re the one who “can build anything.” You can’t set boundaries because you’re the “glue”—and glue doesn’t get to decide where it’s applied.

The praise wasn’t recognition. It was a leash made of compliments.

What Nobody Counts

The startup got my peak performance years. My energy. My creativity. My health. My time with people I love. My ability to be present—actually present—with family.

They got my Saturday mornings and Sunday evenings. They got my 2 AM problem-solving brain. They got my ability to integrate complex systems and deliver “impossible” timelines.

What did I get?

Below-market salary. Vague promises. The privilege of being so valuable I couldn’t leave. And the certain knowledge that the moment I did leave, everything I sacrificed would mean exactly nothing.

The body keeps score. The calendar keeps score. The relationships keep score.

The startup doesn’t keep score. They keep taking until you’re empty, then they act confused about why you’re leaving.

The Deadlines & The Damage

Everything Is Urgent (Except Nothing Is)

Let me tell you about the word "urgent" and how it loses all meaning in startup land.

Everything was urgent. Every single thing.

"Build this so we can sell it and get money." Urgent.

"Build that because a customer relies on it." Urgent.

"Fix this bug." Urgent.

"Add this feature the CEO mentioned in passing." Urgent.

When everything is urgent, nothing is urgent. But try explaining that to management when they're in "growth mode" and every deal feels like the one that'll make or break the company.

The reality? Most of these "urgent" things could have waited. Should have waited. Waiting would have meant building them right instead of building them fast and broken.

But speed was the only metric. Ship it. Get it out there. We'll fix it later.

Later never came. Or rather, "later" was 2 AM when it broke in production and I was debugging the shortcuts we took to ship it "urgently."

The Prototype That Became Frankenstein

Here's a startup classic: a system built for something simple, as a proof of concept, became the main product.

Let that sink in. A PoC—the thing you build with duct tape and prayers to prove an idea works—became the foundation of a commercial product serving paying customers.

We bolted new services onto rotting fundamentals. The architecture wasn't designed to scale because it was never supposed to. The database schema was a nightmare because it was meant to hold test data, not production workloads.

But hey, it worked! It made money! Why would we rebuild?

Because technical debt compounds with interest, that's why. But that's a tomorrow problem, and startups don't think about tomorrow—they think about the next deal, the next demo, the next funding round.

So we shifted things around. Added services. Created integrations. Built a Jenga tower of dependencies on top of a foundation made of matchsticks.

I kept saying we needed to refactor. Rebuild core pieces. Address the fundamental architectural problems.

"Maybe after this sprint." "Once we close this deal." "When we have more time."

Spoiler: we never had more time. We only had more customers stressing a system that was already creaking under the load.

The Sprint That Ate Itself

We had sprints. Actual, planned sprints with stories and points and all the Agile ceremony.

We also found creative ways to completely undermine them.

Hot fixes—not for critical bugs, but for shipping new features mid-sprint. Because someone sold something we didn't have yet, and now it's "urgent" (there's that word again), and we can't wait two weeks until the next sprint.

So we'd hotfix a feature into production. Which meant bypassing code review, cutting corners on testing, and hoping really hard that we didn't break anything.

Sometimes we got lucky. Sometimes we got a 2 AM phone call.

Sprint planning became a performance art of pretending we had a plan while knowing it would be shredded by Wednesday when the CEO came back from a customer meeting with "quick ideas" that weren't quick.

Retrospectives were exercises in documenting the same problems sprint after sprint:

• Too many interruptions
• Unclear requirements
• Scope creep mid-sprint
• Technical debt slowing us down

And sprint after sprint, nothing changed. Because changing would require saying "no" to something, and we didn't have a culture that permitted "no."

The Disaster We Saw Coming

Let me tell you about the time Microsoft changed an API and our entire system broke.

Why did it break? Because we were using their beta APIs.

Why were we using beta APIs? Because they offered functionality we needed that the stable APIs didn't have yet.

Did we read the disclaimers that beta APIs can change at any time without notice? Yes.

Did we ignore them anyway because we needed to ship? Also yes.

And then one day, Microsoft changed the response format. As they explicitly said they might. As was their right with a beta API.

Everything broke. Hard.

We had to reverse-engineer the new response format, update our code, test it (ha—who has time for thorough testing when production is down?), and deploy ASAP.

I remember the manager asking, "How did this happen?"

"Because we used beta APIs that explicitly said they could change."

"Well, why would we do that?"

"Because you needed the feature shipped last quarter, and beta was the only option."

Awkward silence.

The lesson learned? None. The pattern continued. We kept taking shortcuts because "urgent," and I kept being the one cleaning up when the shortcuts led off a cliff.

Cassandra in the Code Review

You know the Greek myth of Cassandra? Cursed to see the future and never be believed?

I was the engineering Cassandra.

"This system will break if too many customers get on. The architecture is bad. The database schema is worse."

Management response: "How many customers until it breaks?"

"I can't give you an exact number. It's not precise math. But we're playing architectural Russian roulette."

"So it's working now?"

"Yes, but—"

"Then let's focus on growing customers. We'll deal with scaling when we need to."

This is the disastrous mindset. Because it still works—barely, borderline, hanging by a thread—you're treated as the negative guy. The pessimist. The one who doesn't understand that startups are about taking risks.

There's a difference between taking smart risks and ignoring structural problems because acknowledging them would require difficult decisions.

I could see the cracks spreading. I could hear the load-bearing walls groaning. I was pointing at the ceiling and saying, "That's going to collapse."

And they were saying, "But it hasn't collapsed yet, so let's add another floor."

When it finally did start breaking—slowdowns, timeouts, data inconsistencies—the response was "Why didn't anyone tell us this would happen?"

I did. Repeatedly. In writing. In meetings. In architecture reviews.

But being right later doesn't undo the damage of not being believed earlier.

My Beautiful Curse (Or: Why I Worked Twice as Hard)

Here's my problem: I have an obsession with writing clean, reusable code that follows common standards. It's part OCD, part professional pride, part deep-seated belief that if you're going to build something, build it right.

Even for proof-of-concepts, I wrote production-level code. Proper architecture. Documented functions. Reusable components. Code that could actually evolve instead of being thrown away.

This didn't make me slower. It made me work more hours.

While others shipped garbage quickly and called it done, I shipped production-quality code on the same timeline. I just worked evenings and weekends to make it happen. I was fast AND thorough—the worst possible combination for my work-life balance.

I could build fast. I had that talent. But I refused to build fast and sloppy.

So I built fast and good, which meant I built fast and exhausted.

The people who shipped garbage quickly had time for hobbies. I had clean codebases and no sleep. They took weekends off. I spent weekends making sure the "quick" solution was also the "right" solution.

And here's the kicker: nobody noticed the difference. They saw "feature shipped" and checked the box. They didn't see the difference between my production-ready code and someone else's time bomb.

Until months later, when their feature broke and mine was being built upon. But by then, everyone had forgotten who built what with care and who just vomited code into existence.

I paid the price for my standards with my time. The company got production-quality code at prototype speeds. I got the privilege of working twice as hard to maintain my principles.

The Pace That Breaks Things (Including People)

The pace was unsustainable. Not in a vague "this is hard" way. In a mathematical certainty way.

You cannot run at sprint speed indefinitely. Eventually, you collapse. The system collapses. The code collapses. The people collapse.

But startups are built on the belief that you can outrun consequences. Move fast enough and technical debt won't catch you. Ship features faster than the old ones break. Grow revenue faster than your infrastructure problems matter.

It works until it doesn't.

And when it stops working, the engineers who were sounding the alarm get asked, "Why didn't you build it more scalable?"

Because I did. I just also had to build five other things at the same time while managing a team and being on-call for production issues.

The things I built properly kept working. They became the foundation everyone else built on. The stable services that didn't collapse when customer load tripled.

But by then, everyone had forgotten who built the foundation. They only remembered who shipped the flashy features fastest, regardless of quality.

I got to be both the tortoise and the hare—winning the race but never being acknowledged because I made it look effortless. The cost of making it look effortless was working double time behind the scenes.

The AI Paradox (The New Layer of Hell)

The CEO Discovers AI

AI is hot. You know what that means? Every CEO suddenly becomes an AI expert.

"AI will learn your codebase and write code for us!"

"This will speed up development and testing!"

"We can move even faster now!"

Oh good. Because what we really needed was to move faster on our foundation of quicksand.

AI-powered IDEs appeared, and suddenly everything was easy. According to people who don't write code for a living, anyway.

The promise was seductive: AI assistants that understand context, generate boilerplate, catch bugs before they happen. Developer productivity through the roof! 10x engineers for everyone!

The reality was... more complicated.

In the Right Hands vs. The Wrong Hands

Here's the thing about AI coding tools: in the hands of someone with architectural mentality, someone who understands patterns and writes code with intention, they're gold.

You need to give explicit instructions. Review the output. Ask for changes. Review again. More changes. Iterate until it matches your mental model and your code standards.

It's a dialogue. The AI suggests, you refine. It generates boilerplate, you shape it to fit your architecture. It's a power tool, and like any power tool, it requires skill to use well.

I used AI assistants. They helped. They sped up the tedious parts—writing repetitive CRUD operations, generating test scaffolding, suggesting patterns I'd use anyway.

But I was also reviewing every line. Refactoring to match our conventions. Ensuring it integrated cleanly with existing systems. The AI gave me a head start, not a finish line.

The Nuclear Bomb in Inexperienced Hands

Now give that same tool to someone inexperienced. Or worse—someone who just doesn't care.

Just a prompt, and it gives you something that works.

Not something good. Not something maintainable. Not something that fits your architecture. Just something that... runs.

Bad architecture? Check. No code reuse? Check. Ballooning technical debt? Check. Code style completely different from existing standards? Check.

The AI doesn't know your codebase's conventions. It doesn't care about your architectural decisions. It doesn't understand that this new feature should reuse that existing service instead of duplicating logic.

It just generates code that compiles. And to someone who doesn't know better—or doesn't care—that's good enough.

Guess Who Loved AI Most?

The people who already wrote sloppy code loved AI the most. Because now they could write sloppy code faster.

The person who used to break things every week? Now they could break things AND generate a mountain of unmaintainable code in the same sprint!

Progress!

They'd take an AI suggestion, paste it in, and ship it. No review. No consideration for existing patterns. No thought about whether this duplicates functionality that already exists three files over.

And guess who had to review this code? And guess who had to debug it when it inevitably broke? And guess who had to refactor it when it became obvious it didn't fit the system?

The same person who'd been doing it all along. Me.

Except now there was more of it. Because AI made it easy to generate code, but it didn't make it easy to generate good code. That still required a human who gave a damn.

The Productivity Paradox

Management saw AI as a force multiplier. "Now our engineers can be 3x more productive!"

What they didn't see:

• The extra time reviewing AI-generated garbage
• The technical debt accumulating faster because bad code was easier to create
• The maintenance burden down the line
• The fact that "working" and "good" are not synonyms

For experienced engineers like me, AI was a modest productivity boost. Maybe 20-30% faster on certain tasks.

For inexperienced or careless engineers, AI was a productivity boost in the worst possible way: they could create problems faster than ever before.

And the problems still landed on the same desks to fix.

The Long-Term Maintenance Nightmare

Here's what nobody talks about: AI-generated code optimizes for "works now," not "maintainable later."

It gives you solutions that work in isolation but don't integrate well. It duplicates logic instead of reusing functions. It generates verbose code instead of elegant code. It follows patterns from its training data, not your codebase's patterns.

Fast now. Fucked later.

I saw it happening in real-time. Features shipped quickly using AI assistance, and three months later we're debugging weird edge cases because the AI solution didn't account for our specific business logic. Or refactoring because the AI duplicated 200 lines of code that should have been a shared utility function.

The "speed" was an illusion. We were just moving the cost from "time to write" to "time to maintain." And maintenance time is always more expensive because it happens under pressure, when things are breaking, when customers are affected.

But try explaining that to a manager who just saw someone ship a feature in a day that "normally" takes a week.

"Look how productive we are!"

Yeah. Until we're not. Until the technical debt comes due. Until someone has to understand and modify the AI-generated spaghetti code at 2 AM.

The Job Security Question

Do I worry about AI replacing engineers?

Not the good ones. Not yet, anyway.

AI can generate code. It can't architect systems. It can't understand business requirements that are vague and contradictory. It can't debug a production issue that involves seven services, three databases, and two third-party integrations that are all misbehaving in concert.

It can't look at a manager's request and say, "That's technically possible but architecturally insane, here's a better approach."

It can't be Cassandra in the code review.

But will companies think AI can replace engineers? Oh, absolutely. That's already happening. "We can hire fewer seniors, give the juniors AI tools, and get the same output!"

Narrator voice: They won't get the same output.

They'll get more code. Faster code. Code that works in the demo. Code that collapses under real-world load and complex requirements.

And then they'll need the expensive senior engineers to come fix it. If those engineers are still around and willing to clean up the mess.

The real threat isn't AI replacing good engineers. It's management believing AI can replace good engineers, making decisions based on that belief, and creating disasters that could have been avoided.

The Learning Burden (On Top of Everything Else)

Oh, and on top of all your existing responsibilities, you're now expected to be an "AI expert."

Learn the tools. Integrate them into workflows. Train others on best practices. Become the "AI champion" for your team.

Because of course that's not a separate role or an investment in training time. That's just something you do, in addition to the architecture, the development, the firefighting, the managing, and the therapy.

"AI will make you more productive!" they said.

What it actually did: add another skill to learn, another tool to maintain, another thing to have opinions about in meetings, and another vector for people to create problems faster than I could fix them.

The promise was leverage. The reality was additional load.

The Bottom Line

AI in coding is a tool. Like any tool, it amplifies the skill of the person using it.

In skilled hands: genuinely useful, modest productivity gains, helps with tedious tasks.

In unskilled or careless hands: a machine gun that shoots technical debt.

And in management's imagination: a magical solution that lets them squeeze more output from fewer people, with no downsides, because they don't have to maintain the code later.

The third one is the most dangerous, because that's where decisions get made.

The AI revolution in coding isn't making everyone a 10x engineer. It's making the gap between good and bad engineers more visible, more costly, and easier to ignore until it's too late.

And guess who's still on call when the AI-generated code breaks at 2 AM?

The Exit & The Truth

The Final Straw (Or: When Managers Outnumber Solutions)

It wasn't one thing. It never is.

It was the slow accumulation of managers instead of engineers. People who needed to justify their existence by having opinions about engineering decisions they didn't understand.

In a company that was 80% engineers, we somehow had too many managers. And every single one needed to have something to say about the technical work to prove they had a role.

Office politics emerged like mold—inevitable when you have too many people competing for relevance and not enough actual work to justify their positions.

Processes multiplied. Not the processes we needed—the ones that would actually help us ship better, faster, safer. No, these were processes for the sake of having processes. Bureaucracy designed to create the appearance of structure while actually just creating friction.

And the people who were good at playing the game—the PR makers, the smooth talkers—they became the new stars. Not the people building the foundation. Not the people keeping the lights on at 2 AM. The people who knew how to position themselves in the political landscape.

I watched the company transform from a place that built things into a place that talked about building things while managers managed each other in circles.

That's when I knew. I was done.

The Long Goodbye

I gave one month's notice. Then I took my accumulated leave on top of that.

Because here's what I did that most people don't: I documented everything. Every system I built. Every architectural decision and why. Every quirk, every workaround, every future consideration.

I had at least two people on every project I'd worked on who had knowledge. I'd been training them all along. Not because I was planning to leave—because I refused to be a single point of failure. I refused to hold information hostage to feel important and irreplaceable.

Everything was open. Everything was transferable. Not because they deserved it, but because that's the professional thing to do.

I could have put my ego on top and left with a bang. Created a hole. Made myself look irreplaceable by ensuring no one could replace me. Sabotaged things through obscurity and knowledge hoarding.

But I'm not that guy.

I wanted to be valued because people understood what I brought to the company. Not because if I left, no one else would know the systems I built. There's a difference between being irreplaceable because you're exceptional and being irreplaceable because you've created artificial dependencies.

That should be the trend. Build systems that outlast you. Train people to take over. Document so well that your absence is felt but not catastrophic.

But here's the truth: most people respect you out of fear, not because you're different and you offer value. They respect you because they're afraid of what happens if you leave and take your knowledge with you.

The Morale Crisis (That Wasn't Really About Me)

There was a moral hit. After all those years, why is he leaving? He was a god here. What happened? How can we replace him?

Some people on my team were ready to follow. "If he leaves, we're leaving."

I appreciated the sentiment. I really did. But I also told them: stay if it works for you, leave when it doesn't. Don't leave because I did. Leave when you realize what I realized.

Meetings happened. One-on-ones. But not to address the reasons I left and fix things. No, no—that would require acknowledging systemic problems.

The meetings were for damage control. For managing other people's morale. For finding the next victim who would do the dirty work.

And here's the beautiful part: one person couldn't do what I did. That should have been a wake-up call, right? "Wow, we were really depending on this person for too much."

But that wasn't how they saw the problem. The problem wasn't that they'd overloaded one person. The problem was they needed multiple people to replace the one person who left.

So they used multiple people. Spread my responsibilities across three or four engineers. Problem solved! (The problem was not solved.)

The Family Reunion That Never Happened

Remember how we were family?

Funny how families work. I left. Family replaced me.

Because it's not "my child left and I miss them" family. It's foster kid family. "That one left? Okay, let's get a new one."

The family was exactly what it always was: a catchphrase. A manipulation tactic. A way to extract loyalty without reciprocating it.

Some people kept in touch. The real ones. The engineers who'd been in the trenches with me. We'd been through actual battles together, not just corporate team-building exercises.

Most people? Vanished. Within weeks. The "family" that would text at midnight when they needed something went silent when there was nothing they needed from me.

The managers who'd called me "irreplaceable"? I haven't heard from them since my last day. Turns out I was very replaceable to them. They found new people to depend on, new engineers to call at midnight.

The CEO who said "you ARE this company"? Radio silence.

It's almost like I was a resource, not a relative. Who could have seen that coming? (Anyone with eyes, that's who.)

The Awakening of the Sheltered

Here's something I didn't expect: the people who worked under me suddenly got responsibilities. And they suddenly realized what had been happening under their nose all these years.

I'd been their shield. Their barrier. I absorbed the chaos, the irrational demands, the midnight calls, the impossible deadlines. I translated management's madness into achievable work. I fought battles they didn't even know were happening.

When I left, that shield disappeared.

And suddenly they were dealing directly with the managers who asked for impossible things. With the CEO who promised features without consulting engineering. With the midnight calls. With the pressure.

Some of them reached out after a few months. "I didn't realize how much you were protecting us."

I know. That was the point. You weren't supposed to realize. I wanted them to focus on building good things, not on navigating organizational dysfunction.

But now they knew. Now they understood why I left. Some of them followed me out within six months. Others stuck it out, hoping things would improve.

They didn't improve. The system doesn't improve. It finds new people to grind down.

The Anticlimactic Aftermath

Guess what happened after I left?

Nothing.

The systems I built kept running. The documentation held up. The people I'd trained stepped up. The company survived.

Part of me is proud of that. I built things properly. I transferred knowledge. I didn't sabotage anything on the way out. That's the professional thing, and I can live with that.

But another part of me—the bitter, human part—noticed that my absence proved exactly what they believed: everyone is replaceable.

They probably used my smooth exit as evidence that I wasn't as critical as people thought. "See? He left and nothing broke. We're fine."

They didn't count the cost of spreading my work across multiple people. They didn't measure the loss of institutional knowledge that doesn't fit in documentation. They didn't notice the absence of the person who could see around corners, who knew which shortcuts were safe and which were disasters waiting to happen.

Or maybe they did notice, and they just didn't care. Because the company was still making money, still shipping features, still growing.

The foundation I built was solid enough to carry them forward without me. That's good engineering. But it's also invisible. Nobody sends you a thank-you card for building things so well that they don't break when you leave.

The Replacement That Wasn't

They didn't replace me with one person. They couldn't.

They split my responsibilities across multiple people. Which means they knew—they had to have known—that what they were asking of one person was unreasonable.

But acknowledging that would mean admitting they'd exploited me. Easier to just spread the load and move on.

I don't know if those people are happy. I don't know if they're drowning. I don't check in on the company anymore. That chapter is closed.

What I do know is this: the job I left got parceled out to multiple people because one person doing all of it was unsustainable. But they'll do it to the next person too. And the next. Because the system doesn't learn.

The system just finds new people to grind down, calls them "family," and starts the cycle again.

Everyone Is Replaceable, But Your Time Isn't

Here's the brutal truth I learned: everyone is replaceable. Including you. Especially you.

The company will survive without you. They'll find someone else. Multiple someone elses, if needed. The work will continue. The products will ship. The money will flow.

You are not irreplaceable to them, no matter what they say in your performance reviews.

But here's the part they don't mention: your time IS irreplaceable. The weekends you gave them? Gone forever. The sleep you sacrificed? Your body remembers, even if they don't. The relationships that withered because you were always "in the middle of something"? Can't get those back.

The years you spent being "the guy who can do anything on any stack" were years you can't relive. That time is gone. You spent it making them successful, and they'll spend about five minutes missing you before moving on.

They'll replace you in a heartbeat. But you can't replace your time.

That's the exchange rate they don't put in the job description. Your irreplaceable time for their easily replaceable position.

I left with my documentation complete, my systems stable, and my knowledge transferred. I left professionally, gracefully, properly.

But I also left knowing that the "family" would forget me in weeks, that my absence would barely register, and that everything I sacrificed for them would be treated as just part of the job.

The job they filled with multiple people. Because even they knew one person couldn't do it all.

They just didn't care that one person was trying to.

The Mediocrity Paradox

How to Get Ahead: A Startup Guide

Want to know the secret to career advancement in a startup? It's simple: be lucky enough to find one good team member, then sit back and take credit.

I watched it happen repeatedly. People who shipped one feature per month—maybe—but were positioned as "managerial material who know how to build teams."

Meanwhile, there were people like me who led by example. Shipping multiple features, inevitably a few bugs too (because that's what happens when you actually build things at volume). But we weren't "managers who can build teams." We were just the horses pulling the cart.

The difference? The political operators knew how to position themselves. They knew how to take credit without taking risk. They knew how to be in the right meetings, say the right things, align with the right people.

And they knew—crucially—how to let people like me do the actual work while they managed the narrative.

"Look at my team's output!" they'd say, gesturing at work I did.

"Look at how I'm scaling our capabilities!" they'd say, after I trained junior engineers.

"Look at my leadership!" they'd say, while I was the one on calls at midnight solving actual problems.

They got promoted. I got more work.

The Battle for Every Penny

Until I became "irreplaceable," I had to fight for every penny. Every. Single. Penny.

Raises weren't given for performance. They were negotiated, extracted, fought for. Every review cycle was a battle to justify my value with metrics, examples, and evidence that should have been obvious to anyone paying attention.

And when they finally feared I was going to leave—in my early days—I got a good raise. But not for free. Oh no.

"Now you get the big bucks," they said. Unspoken: "Now we own your soul."

The raise came with invisible strings. More responsibility. Higher expectations. The understanding that I'd just signed away my right to boundaries because they'd "invested" in me.

It wasn't compensation for value delivered. It was a golden handcuff disguised as recognition.

And that pattern continued. Every time I proved my worth, the reward was more work, not more money. The money only came when I was halfway out the door and they panicked.

That's not a compensation strategy. That's hostage negotiation.

The People We Protected (To Our Own Detriment)

Here's something we did wrong: we covered for people.

The ones who did less but survived because we picked up their slack. The ones who hid behind processes, blamed others, and abused our patience and good hearts.

We enabled them by being too competent. We filled their gaps, fixed their mistakes, and let them coast because it was faster than fighting to hold them accountable.

And management loved it. Why fire the weak link when the strong links will just carry the extra weight? Why address performance problems when high performers will compensate?

We thought we were being team players. We were actually being suckers.

Those people survived—sometimes thrived—because we made them look functional. And they never had to get better because we never let them fail visibly enough to face consequences.

I should have let more things break. Let more of their mistakes be visible. Let management see the actual cost of keeping deadweight.

But I cared too much about the product, the customers, the team. So I fixed it. And they stayed. And nothing changed.

The Age Tax (Or: How Experience Became a Liability)

Searching for new jobs with all my experience should be easy, right? That's what I thought.

But not in the AI era. And definitely not in Greece.

Why hire a 40+ person when you can hire someone young for half the money but twice the title?

Why hire a seasoned person for Head of Engineering when you can hire an early-30s person, pay them half, make them VP, and let them ask ChatGPT how teams are managed and how to write and ship clean code?

I'm not saying young engineers aren't capable. Some are brilliant. But there's a pattern in hiring now: youth is valued over experience because youth is cheaper and doesn't question as much.

A 25-year-old who's eager and underpaid will work the same hours I worked without realizing they're being exploited. They haven't learned yet. They're still in the "this will pay off later" phase.

I've already learned that "later" doesn't come.

And companies know this. They know that experienced engineers cost more and push back more. We've seen the patterns. We know which shortcuts lead to disaster. We say "no" more often and "maybe" less often.

That's not desirable anymore. They want people who'll say "yes" quickly and figure it out later. They want enthusiasm over wisdom.

In the AI era, there's this belief that experience matters less because AI can fill the gaps. Need to know how to architect a system? Ask ChatGPT. Need to learn a new framework? AI tutorial. Experience is downloadable now, right?

Except it's not. AI doesn't give you the pattern recognition that comes from seeing three different architectures fail in similar ways. It doesn't give you the judgment to know when to take a shortcut and when that shortcut will cost you six months of pain.

But explaining that in a job interview to a 30-year-old hiring manager who's never lived through a major technical failure? Good luck.

The market has decided that experience is expensive and therefore optional. Especially when you can get someone cheaper who looks good on LinkedIn and can prompt-engineer their way through problems.

Until those chickens come home to roost. And they will. But I won't be there to fix it at 2 AM anymore.

The Exhaustion of Fighting Your Own Corner

I was tired. So tired.

Tired of fighting battles to prove my value because I was never a PR person or a CEO favorite masquerading as a manager.

I was the loud voice highlighting bad decisions. The one who advocated for my team. The one who assumed responsibility and blame when things went wrong, even when it wasn't my fault.

That's not how you get ahead. That's how you get more work.

The people who got promoted were the ones who knew how to align with leadership, how to frame problems as opportunities, how to take credit and deflect blame.

I took blame to protect my team. They deflected blame to protect their image.

I highlighted problems to fix them. They highlighted successes to build their brand.

I spoke up about bad decisions because someone needed to. They stayed quiet or nodded along because career advancement requires not making waves.

Every fight was exhausting. Every conversation where I had to prove—again—that I was delivering value. Every review cycle where my accomplishments were "noted" but not rewarded. Every time someone else got promoted for managing a team that I'd built and trained.

It wears you down. Death by a thousand paper cuts of being undervalued.

And the worst part? I couldn't stop. I couldn't stop advocating for my team because they needed someone to fight for them. I couldn't stop highlighting bad technical decisions because someone needed to be the voice of reason. I couldn't stop taking responsibility because that's who I am.

But it cost me. Every time.

The Meritocracy Myth

Startups love to talk about meritocracy. The best ideas win. Performance matters. We promote based on results.

It's bullshit.

What actually gets rewarded:

• Being visible more than being competent
• Managing up more than managing well
• Taking credit more than taking responsibility
• Looking busy more than being productive
• Aligning with leadership more than being right

The people who thrived weren't the best engineers. They were the best politicians.

And maybe that's fine. Maybe that's just how organizations work. But don't call it meritocracy. Don't pretend that hard work and technical excellence are what matter.

They matter right up until they don't. Right up until the person who ships one feature per month but plays golf with the CEO gets promoted over the person who's carrying the technical foundation of the entire company.

I watched mediocre people thrive while excellent people burned out. And the system called that "culture fit" and "leadership potential."

The Pattern You Can't Unsee

Once you see the pattern, you can't unsee it:

The people who succeed in startups aren't always the ones who build the best things. They're the ones who build the best narratives about the things they're adjacent to.

They don't need to be exceptional engineers. They need to be exceptional at appearing exceptional.

They don't need to solve hard problems. They need to be visible when hard problems get solved.

They don't need to work the midnight hours. They just need to be in the meeting the next morning talking about "how we handled" the crisis.

And once I saw that pattern, I couldn't participate in it anymore. I couldn't play the game. I couldn't pretend that the performance was the substance.

So I did what the system considers failure: I left.

But I left knowing I built things that lasted. That I trained people who became better engineers. That I solved problems that mattered.

The system won't remember me. The "family" already forgot me. The mediocre people who played the game better will get the promotions and the recognition.

But I sleep at night knowing I built things right, even when no one was watching. Even when it cost me the political advancement.

That has to be enough. Because it's all I've got.

What I'd Tell My Younger Self (Advice Without the BS)

The New Startup (Or: How I Learned Nothing and Repeated Everything)

You'd think after everything, I'd have learned. You'd think I'd recognize the patterns, avoid the traps, set boundaries from day one.

You'd be wrong.

I joined a new startup. Different company, same promises.

The payments? They'll come "soon." Just need to close this funding round. Just need to hit this revenue target. Just need to get through this quarter.

"Soon" is a startup's favorite word because it means nothing and everything. It's a promise without a timeline. A commitment without commitment.

The equity? Oh, we'll formalize that. After we structure the cap table. After the lawyers review it. After we close the round. After, after, after.

Millions were promised. Stock options discussed in excited, vague terms. "When this thing takes off, you'll be set."

But nothing was given. Just empty promises floating on a sea of "trust us."

And like an idiot, I trusted. Again.

Because I wanted to believe that this time would be different. That this company valued engineers. That the "family" rhetoric would actually mean something this time.

It didn't.

The pattern repeated because the system doesn't change. Only the names change. The game stays the same.

So here's what I learned—what I wish I'd known before, what I'm telling you now:

Know Your Worth (And Take It)

Your market value is not what they offer you. It's what the market will pay for your skills.

Research it. Know it. Own it.

Then take it. Don't accept below-market rates for equity promises. Don't trade real money today for hypothetical money tomorrow. Don't believe that "once we're profitable" or "after the next round" actually means anything.

If they value you, they'll pay you now. Not later. Not "soon." Now.

And if they can't pay you market rate? They can't afford you. That's not your problem to solve by accepting less.

Work Smart, Not Just Hard

I worked hard. Really hard. Multiple hats, long hours, weekends, midnight calls.

Know what I should have done? Worked smart.

Choose your battles. You cannot fight all of them. You'll exhaust yourself fighting for things that don't matter while missing the things that do.

Play the game. I hate saying that, but it's true. You don't have to be a political operator, but you do need to understand that visibility matters, that perception shapes reality, that doing great work invisibly is a recipe for being overlooked.

And never—NEVER—fight dumb people. You will not win these battles. You'll just waste energy that could go to actual problems.

Dumb people are protected by their inability to understand why they're wrong. You can't logic someone out of a position they didn't logic themselves into.

Let them fail visibly. Document your objections. Then step back and let consequences be the teacher.

Save your energy for battles you can actually win.

Use Tools Smartly (Learn From My Obsession)

Always write code as if it's going to be production code. Because it will be.

That "quick PoC"? Production code. That "temporary solution"? Production code. That "we'll rebuild it later"? You won't. Production code.

But here's the key: deliver fewer features in your PoC or MVP with production-quality code rather than ship multiple features with too many corners cut.

Speed with quality is better than speed with garbage. And it's possible if you use the tools right.

Use what the cloud offers to deliver fast:

• ECS or Azure Container Apps—not because they're trendy, but because they work and they're fast to deploy
• Docker everything—containers are your friend
• Dapr for microservices if you go that route (you will thank me later when you need to refactor communication patterns)

But here's the critical part: Do not make microservices because it's a trend. Analyze and build smart.

Monoliths are not bad. A well-structured monolith is better than a poorly designed microservices mess. Don't let anyone shame you into over-engineering your architecture because "that's what Netflix does."

Netflix has different problems than your startup. Build for your problems, not theirs.

Start with a modular monolith. Split it into services when you have a reason, not before. Premature distribution is the root of all debugging nightmares.

Keep Friends Outside Work

This one hurts, but it's true: keep your real friends outside work.

Go to team bonding events. Be professional. Be friendly. But don't overinvest in office relationships.

Your family is your family. Your wife. Your kids. Your dog. The people who'll be there when the startup implodes or when you leave or when things go sideways.

Everyone else is a colleague. Not a friend. At least not a long-lasting friend.

There are exceptions. A few people from the trenches who become real friends. But they're rare, and you won't know who they are until you leave and see who's still there.

The "work family" will evaporate the moment you're not useful to them. Plan accordingly.

Don't let the startup consume your social life. Don't make your identity about your job. Don't tie your self-worth to your work relationships.

Because when you leave—and you will leave, or they'll leave you—you need something left. Someone left. A life that exists independent of your job title.

Listen to Your Compass

Keep your values. Listen to your moral compass and your ethical compass.

Work smart and passionate. Build things you're proud of. Solve problems that matter.

But when the passion is gone? When you're working against your beliefs and values? When you see politics and mediocrity thrive while excellence is ground down? When payments will come "soon"? When stocks are not given but millions are promised?

Leave.

Don't wait for it to get better. It won't. The system doesn't fix itself. It finds new people to grind down.

Find your next opportunity. A company building technology and products you'll actually enjoy working on. A tech stack that excites you. A problem space you believe in. Or at least something that doesn't make you miserable.

You don't need to change the world. You don't need to cure cancer or revolutionize industries.

You just need a cause you believe in—or at least one that doesn't violate your values. A product that doesn't make you feel dirty for building it. A team that doesn't make you want to quit every Monday.

A job that lets you get out of bed happy, or at least not dreading the day.

That's the bar. It sounds low, but in startup world, it's surprisingly rare.

The Red Flags I'll Never Ignore Again

If I could go back, here's what would make me walk away in an interview:

Language red flags:

• "We're a family" (Translation: we'll guilt you into overwork)
• "We work hard, play hard" (Translation: we work hard, period)
• "Equity over salary" (Translation: we can't afford you and hope you don't realize it)
• "Wear many hats" (Translation: we're understaffed and you'll do everything)
• "Fast-paced environment" (Translation: chaos with no processes)
• "We move fast and break things" (Translation: we have no idea what we're doing)

Structural red flags:

• More managers than engineers
• Can't tell you the funding runway
• Vague about equity structure
• "We'll formalize compensation after you start"
• Processes that exist to justify managers, not to help engineers
• "Trust us" as a compensation strategy

Cultural red flags:

• Engineers working visibly long hours (that's not dedication, that's unsustainable)
• High turnover (ask how long the person you're replacing lasted)
• Can't introduce you to the team before hiring
• Leadership with no technical background making technical decisions
• "We're going to disrupt [industry]" without understanding [industry]

The One Question That Reveals Everything

In interviews, ask this: "Can I talk to someone who left the company?"

Watch their reaction. If they hem and haw, that's your answer.

If they say "everyone who leaves is bitter" or "we don't keep in touch with people who leave," that's also your answer.

A healthy company will let you talk to alumni. They'll have people who left on good terms and will speak honestly about the experience.

An unhealthy company will have burned bridges with everyone who left.

That tells you everything you need to know about how they treat people.

The Boundary I Wish I'd Set

If I could go back and set ONE boundary from day one?

"I don't work weekends unless there's a genuine emergency. And I define emergency, not you."

Then defend it. Ruthlessly.

The first time they ask you to work Saturday, say no. The first time they expect Sunday availability, push back. The first time they Slack you at 11 PM with something non-urgent, don't respond until morning.

Train them on your boundaries early. Because if you don't, they'll train you to have none.

I know it feels risky. "What if they fire me?" "What if they think I'm not committed?" "What if I miss out on opportunities?"

Here's the truth: if they'll fire you for having boundaries, you don't want to work there anyway. You're just delaying the inevitable misery.

And companies that respect boundaries? They exist. They're not unicorns. They're out there.

But you'll never find them if you keep accepting jobs at companies that exploit the lack of boundaries.

When to Leave (For Real This Time)

You know it's time to leave when:

• You're explaining the same problems in the same retrospectives with no change
• Your technical warnings are consistently ignored until they become production fires you have to fix
• You're being compensated with promises instead of money
• The politics matter more than the product
• You're doing the work of three people and being told "that's startup life"
• Your health is declining (sleep, weight, stress, relationships)
• You dread Monday morning
• You've stopped learning and started just surviving
• The mission you believed in has been replaced with "make investors happy"
• You're being valued for your compliance, not your competence

Don't wait for the perfect exit. Don't wait for it to get better. Don't wait for them to recognize your value.

It won't. They won't.

Leave when you've learned what you came to learn. Leave when the cost exceeds the value. Leave when your gut tells you it's time.

Trust that instinct. It's trying to protect you from what your hope is blinding you to.

The Passion Trap

Startups love "passion." They want "passionate" people. They screen for "passion" in interviews.

Here's what they mean: they want people who'll sacrifice everything for the mission. Who'll work for less money because they "believe." Who'll give weekends and evenings and health because they're "passionate."

Passion is a tool they use to extract more from you for less compensation.

Real passion is loving the craft. Enjoying the problem-solving. Taking pride in building things well.

Fake passion is working yourself to death for someone else's equity.

Be passionate about your skills. Be passionate about learning. Be passionate about building quality things.

But don't be passionate about a company. Companies don't love you back. They can't. They're legal entities designed to generate returns for shareholders.

Work with passion. But work for compensation. Fair, market-rate compensation. In actual money, not promises.

And when someone questions your "passion" because you won't work unpaid overtime or accept below-market salary, remember: that's not about passion. That's about exploitation.

The Greek Wisdom (Or: What My Yiayia Would Say)

My grandmother would have seen through all of this immediately. She'd have said something like:

"They promise you the moon, but they won't give you bread. Take the bread. The moon is very far away."

She'd be right.

Take the bread. The compensation. The work-life balance. The respect. The boundaries.

The moon—the equity, the promises, the "soon," the "we're going to be huge"—is very far away. And most startups never reach it.

Don't starve yourself chasing moonlight when there's bread on the table somewhere else.

The Uncomfortable Truths

Where I Am Now

I'm up for my next adventure. My next career milestone. But I'm wiser now. And pickier—at least as far as I can be in an era where jobs aren't exactly plentiful and age isn't an asset on your resume.

I know what I'm worth. I know what I won't accept. I know the red flags to run from.

The question is whether I'll have the luxury of running. Or whether I'll have to compromise again, tell myself "this time will be different," and hope I'm right.

The market isn't kind to experienced engineers right now. Companies want youth and enthusiasm over wisdom and boundaries. They want people who'll say "yes" eagerly instead of "let me think about that" carefully.

But I'm done pretending to be something I'm not. Done accepting promises instead of compensation. Done being "family" to organizations that see me as a resource.

If that makes me unhireable, so be it. I'd rather be unemployed than exploited.

(I hope I don't have to test that conviction, but we'll see.)

To the Engineers in the Trenches

What I wish I'd understood earlier:

Money doesn't bring happiness, but it pays the bills. And the more, the better.

Don't let anyone shame you for wanting fair compensation. Don't fall for the "passion over paycheck" rhetoric. You can be passionate AND paid well. They're not mutually exclusive, despite what underfunded startups want you to believe.

But here's the truth: chasing always more, then more, in exchange for your soul? Not worth it.

Work is not family.

No matter how many times they say it. No matter how many team dinners and bonding events. No matter how much the CEO hugs you and tells you "you ARE this company."

You're an employee. They're an employer. It's a transaction. And that's okay. That's healthy, actually.

Real family doesn't require you to sacrifice your health for their success. Real family doesn't forget you the moment you leave. Real family doesn't replace you and move on without looking back.

A CEO will tell you everything you need to hear.

Don't trust anything. Or trust nothing—same difference.

They don't love you. They're pouring ego fuel into your reservoir to keep you running. That's their job. To motivate, inspire, extract maximum value.

Your job is to protect yourself while delivering value. Those aren't contradictory goals.

Work smart. Know your value. And always justify it.

But here's the key: if you actually know your value, justifying it cannot take more than 40 hours per week.

If you're consistently working 60, 70, 80 hours and still feel behind? Either you're overestimating your value, or you're caught in the "we're family and work hard" trap.

Neither is sustainable. One is delusion. The other is exploitation.

Figure out which and act accordingly.

To Startup Leadership (If You're Actually Reading This)

I know what you're thinking: "This guy is giving advice against working. He's telling people to do less. He's poisoning the well of enthusiasm and hustle that makes startups work."

What you're failing to understand is this:

If you actually listen—to me, to this article, to your engineers when they tell you something is broken—you could deliver more with less.

Create smart processes, not bureaucratic ones. Processes should remove friction, not add it. They should protect engineers from chaos, not create more of it. If your processes exist to justify management, not to help teams ship, they're the wrong processes.

Allow people to work smart. Not just hard. Not just fast. Smart.

That means giving them time to build things right. Time to refactor. Time to address technical debt before it becomes technical bankruptcy. Time to think, not just execute.

Stop interfering. Provide an environment where a roadmap can be created and followed. Then get out of the way. Your job is to enable, not to micromanage every technical decision.

Trust your engineers. If they say something will take three months, it takes three months. Saying "I need it in three weeks" doesn't change physics—it just changes whether you get a quality solution or a time bomb.

Do these things—actually do them, not just talk about them in all-hands meetings—and you'll be able to deliver more with less. Your people will be happy. Your investors will be more happy. Your product will be better.

You just need to adapt your MS-DOS era brains to the AI era.

And by that I mean: think modern. Understand that outcomes are not directly related to work hours. Understand that treating people well doesn't make them lazy—it makes them loyal and productive.

Don't think that AI will write free code. Think that skilled engineers using AI thoughtfully will build better things faster—if you give them the environment to do it.

Hire adults. Pay them well. Trust them. Get out of their way.

It's not complicated. It's just hard for ego-driven leadership to accept that they're not the reason for success—their team is.

The Uncomfortable Truths We Don't Say

Truth 1: Most startups fail. Your equity is probably worthless. Plan accordingly. Don't sacrifice real compensation for hypothetical windfalls.

Truth 2: "Changing the world" is marketing. Most startups are solving problems that range from "mildly useful" to "completely made up." That's fine—there's dignity in building useful things. But don't drink the Kool-Aid that you're on a mission to save humanity when you're building a SaaS tool for project management.

Truth 3: The grind is not a badge of honor. Working 80-hour weeks doesn't make you exceptional. It makes you exploited. And it's unsustainable. The people who brag about their hours are either lying or headed for burnout.

Truth 4: You're replaceable. Everyone is. Accept it. But your time isn't replaceable. Your health isn't replaceable. Your relationships aren't replaceable. Don't sacrifice the irreplaceable for a company that'll replace you.

Truth 5: "Passion" is often code for "we can't afford to pay you properly." If a company's primary selling point is passion and mission instead of fair compensation and reasonable working conditions, they're telling you they have nothing else to offer.

Truth 6: The system doesn't change. Individual bad companies might improve. Individual good leaders might exist. But the overall startup ecosystem—the VC-funded, growth-at-all-costs, exploit-engineers-while-they're-young model—that doesn't change. It finds new people to grind down.

Protect yourself accordingly.

The Final Word

This isn't an anti-work manifesto. I love building things. I love solving hard problems. I love the craft of engineering.

This is an anti-exploitation manifesto.

Work smart. Work well. Work with passion and pride.

But work on your terms, for fair compensation, with boundaries that protect your health and relationships.

The startup will survive without your martyrdom. Or it won't. Either way, that's not your problem to solve with your soul.

Save your soul first. The code will be rewritten anyway.

And remember: you're building someone else's dream. Make sure you're getting fairly compensated for it—in money, in experience, in growth, in reasonable working conditions.

If you're not, if it's all promises and "soon" and "we're family," you're not building a dream.

You're being used.

Know the difference. Act accordingly.

Now go build something amazing—on your terms.

Author's Note

If you're a CEO or manager reading this and you're angry: Good. That discomfort is information. Sit with it. Ask yourself why this hit a nerve. Maybe there's something here worth listening to.

If you're an engineer reading this and you're nodding along: You're not alone. These patterns are everywhere. Trust your experience. Protect yourself. You deserve better.

And to everyone else: the best time to set boundaries was day one. The second-best time is now.

Don't wait for permission. Don't wait for it to get better. Don't wait until you're completely burned out.

Your time is finite. Your health is finite. Your relationships are finite.

Spend them wisely. On things and people that actually give back.

Not on companies that'll take everything and call it "family."