r/TechLeader

▲ 23 r/TechLeader+3 crossposts

I was on a team where the CEO ignored every bottom-up warning from engineering for two years and then blamed the market when the product stalled. The roadmap was set in stone and customer feedback was treated as a distraction

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?

reddit.com
u/Popular-Penalty6719 — 20 hours ago
▲ 85 r/TechLeader+1 crossposts

Why did every engineer we hired after headcount 20 reduced our per-person productivity?

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?

reddit.com
u/Popular-Penalty6719 — 8 days ago