u/Popular-Penalty6719

Be careful using Hermes Kanban!
It's awesome, I'm using it. But setting it up for my first project, I've set my projects folder to work just there.
HUGE mistake. At some point, running in the background, it just deleted ALL my projects!
Everything, all my work was gone!

Of course I already changed Kanban configuration but I could only recover what was in git or backups and what the agent remembered.

Something I expect to work next time (for mac):
chflags uchg /your/protected/directory (adds an immutable flag that allows only the owner to delete, in theory). If anyone has a better advice I'll appreciate it.

I joined a company where the CEO had a very clear vision of what the product should become, with a three year roadmap, detailed feature list, and slide decks full of confident projections. The problem was that the engineers and middle managers who talked to customers every day kept coming back with signals that didn't match the roadmap. Customers were asking for simpler integrations and reliability improvements, not the ambitious new platform features the CEO had planned. Every sprint retrospective, the same feedback surfaced. And every time, leadership dismissed it as noise from people who didn't see the big picture.

Two years later, the company had spent millions building a product suite that nobody was asking for while ignoring the core product that was slowly breaking under its own complexity. The CEO held an all hands and said the market wasn't ready for their vision yet. But the market had been telling us exactly what it wanted the whole time. We just weren't listening.

I've been reading about this dynamic between dogmatic and pragmatic strategy modes, and from what I've seen the trouble starts when you commit to the wrong mode for too long. The money keeps coming in and the complexity keeps growing, and the gap between what leadership wants and what the market needs gets wider until something breaks.

Has anyone else here worked somewhere where the roadmap was set in stone and the CEO treated customer feedback as a distraction?

I worked at two companies where interviewing thirty people a day was completely normal. Not because we had a sudden spike in demand, but because the CEOs were so good at raising money that hiring became the product strategy.

At both places, the playbook was identical. Raise a big round, set a three-year goal that looked impressive in a pitch deck, then reverse-engineer a roadmap to match the story we had sold to investors. That meant creating more teams, adding more features, and constantly expanding the headcount to show momentum. I sat in roadmap reviews where every justification traced back to the pitch deck, not a customer conversation.

The CEOs weren't malicious. They were just really good at raising money and the problem is that raising money fabricates demand based on the power of convincing investors, not real customer demand. The excitement of the next round drowned out the real market feedback.

I spent entire weeks in back-to-back interviews while our actual product stagnated. We were hiring people to manage the complexity of hiring people. The capital had stopped being fuel and turned into a production line for internal bureaucracy.

That experience broke my assumption that more money equals more progress. Now I think hypergrowth is just bad money in disguise, a way to mask the gap between what investors want to believe and what customers actually need. Has anyone else watched a company hire aggressively into a demand curve they mostly invented in boardrooms?

My first week at a recently-funded SaaS company, the CTO walked me through a roadmap that had "AI Analytics Suite" on it. I asked which customers had requested it, and he just said "none yet, but data is the future". The product had solid traction with active users, and the founders had raised enough to triple the team. But instead of talking to customers, the leadership team started running "vision workshops" to decide what the product should become. They brought in a squad of engineers and designers to build a dashboard analytics suite because the CEO convinced himself that was the best thing to do. Not a single paying customer had asked for it.

A year later, the analytics feature went live and very few customers used it. The company had burned through most of its runway and started laying people off. The money had acted like a sedative, and nobody felt the urgency to validate costs and customer demand. Because they assumed they could afford to be wrong, they stopped checking if they were right, and definitely the CEO was too arrogant and stupid to think he knew better than his customers just because he managed to convince investors to inject more money. The funding turned out to subsidize a detachment from the reality of what customers actually wanted instead of accelerating their growth.

I keep wondering if the real danger of raising money is the quiet permission it gives you to ignore what the market is actually asking you to do, rather than the dilution or the pressure everyone warns you about.

Has anyone else seen a company get too proud and overconfident because they had enough VC money to burn?

A few years ago I joined a company that had just raised a Series B. We had 14 engineers and a pretty clear roadmap. Within a year and a half we grew to 35 engineers because in theory, more people equals more output. That assumption was wrong in a way I didn't understand until I spent some time trying to calculate.

We started to ship fewer features per engineer as we grew. At 14 people every engineer shipped roughly one meaningful improvement per sprint. By 25 people we were down to maybe 0.6. By 35 it was closer to 0.4. The total output was higher but only because we kept hiring, and the curve was flattening faster than I expected.

The talent wasn't the issue because the new hires were genuinely great. What changed was the amount of time they could spend doing their actual job vs coordination meeting time and chores around the actual job. Every new person expanded the communication graph, which meant more meetings, more alignment, more status updates, more review cycles, more handoff delays. A feature that used to need two people now needed four approvals. A decision that used to be a Slack thread turned into a 45-minute meeting with a dozen people in it. And this last thing is a pattern I saw in multiple companies, we don't want to exclude anyone so everyone is invited, even though half of the attendees spend the whole meeting on Slack anyway.

My understanding is that the first few engineers you add generate a lot of value because the overhead they introduce is near zero. But beyond some threshold every new engineer doesn't just cost their salary but also coordination work, communication work, management work, etc. The overhead from the growth starts consuming more value than the new person produces, and suddenly you're hiring just to manage the complexity that hiring created which ends up sacrificing profitability.

Has anyone actually calculated the coordination cost per new hire before making a decision to hire? At what team size did you notice per-person productivity starting to decrease, and what did you do when you saw it? Is 20 some kind of special number of that was just my experience?

Last year I was running a five-person team and someone handed us a feature that was genuinely simple: parse some data, display it in a dashboard, two weeks of actual work maybe three if you count testing. Somehow it took four months. We finished the code in two weeks, like we estimated. But then the platform team had to review the API contract, who had their own backlog, and someone realized the dashboard touched a data pipeline another team owned, which meant a schema review, which meant two more meetings. None of this was anyone's fault because everyone was busy doing their jobs. Every handoff added another week of waiting, and every week of waiting triggered another stakeholder asking for a status update, which triggered another meeting to produce the status update, which ate the time we could have used to unblock ourselves.

The delay wasn't linear because the overhead was generating more overhead. A two-week delay created a coordination meeting, which created an action item, which created a dependency on someone who wasn't in the room, which created another meeting. The process was feeding itself and the only thing we were shipping was alignment. By month three I stopped tracking the timeline and started counting how many people were now involved who had nothing to do with the code: fourteen people across five teams, and the original two-week feature hadn't changed in scope. The complexity had moved from the software into the human circuitry we built to manage it, and that circuitry had developed its own appetite.

I've been wondering how many teams are in this position right now, paying this invisible tax without ever calculating it. I'm talking about the quiet compounding cost of every architectural decision that adds friction to the system, not the obvious refactor conversation.

Has anyone else actually calculated the actual cost of a feature that should have been simple but turned out to be so complicated? What did you find?

At my last company, the CEO was genuinely impressive at raising money. And that skill, which sounds like a pure positive, ended up being one of the biggest reasons the tech debt never got paid down.

We had this monolith that was already showing its age when I joined. Interdependent modules, features taking weeks that should have taken days, a number of microservices in the intent to extract functionality but keeping the monolith in sync instead of killing it, the usual. But every time the pain started to build and the team started talking about refactoring, another funding round would close. Apparently there was budget for more hires, more process, even more M&As! But resources to adjust the architecture to the actual demand?

Five years later when I left, they were still struggling. The business side saw the tech department as a black box that kept costing more and delivering less, so they added reporting layers and micromanagement. Those layers made the refactoring even harder. It became a self-reinforcing loop. Easy money removed the urgency to simplify, so complexity kept growing and coordination costs piled up. Those costs triggered more process, which ate into the time engineers had to actually fix anything.

What I couldn't shake was the economics underneath it. The complexity we were maintaining had no demand behind it because obviously no customer was asking for it. But the easier money got, the more of it we tolerated, so the liability kept compounding while the funding just kept the cycle going. I started wondering if every dollar we spent maintaining that mess was effectively subsidizing something the market would never reward.

Have you seen this happen? A company that could afford to stay messy, so it did? I'm wondering if the complexity, and its monetary cost, ever actually caught up to them or if some companies just manage to outrun it forever.

I used to think the biggest bottleneck on my team was code review. Turns out, it was everything around the code.

Last year I was running a team of eight engineers. We had this feature that touched three different services. Nothing crazy. But every time someone needed to ship something, they had to ping the backend guy, wait for the DBA to approve the schema change, sync with the frontend dev on the API contract, and then circle back with QA on the test plan.

Nobody was slow. Nobody was blocking on purpose. But a two-day task would take two weeks to actually ship. The work itself was fast. The coordination around the work was what killed us.

I started tracking it. Not the code time. The "waiting for someone to be available" time. The "let me explain the context again" time. The "oh I thought you were handling that" time. It was terrible. Easily 40% of every sprint was just alignment overhead!

The worst finding was the morale hit. Engineers were frustrated by the feeling of being stuck. That limbo state where you can't move forward because three other people need to be in the loop first.

I've been thinking about the natural cost of interdependence as a kind of tax. The more coupled your systems and teams are, the more you pay in human coordination. And it scales faster than the work itself.

Has anyone else tracked this kind of thing? What did the numbers look like for you?

I have created 90+ agent skills to use in my OpenCode with different tasks.

Is there any physical limit? Can I just keep creating more as I need?

How do agent skills actually work?

As far as I understand, a skill only loads into the context window when it's needed, so all others are not used at all.

Is that correct?