Hacker News Reader

Decades ago when I was getting started there was a team that fell way behind and everyone on the team worked weekends and many days until midnight and finally delivered some buggy arguable product 6 months late. They were hailed as heroes. No one even noticed me and my team delivering on time. I learned a valuable and entirely inapplicable lesson.

IME this can sometimes be overcome with a bit of self promotion. Don't let accomplishments be forgotten or overshadowed. It is a political game.

Also teach the execs that heroism doesn't scale. We all want to be entertained by the hero stories, but no one actually wants to live in a world that requires high-visibility heroics.

I understand this intellectually but it is just exhausting

> They have been struggling to deliver even though the have almost twice as many engineers.

My experience tells me that they struggled because they had twice as many engineers.

I don't think I've been to a 20+ person project which could honestly be called "successful". Hard to say if it's a symptom or a cause. Personally I lean towards the former, because when someone tries to throw people at a problem they either don't know what they're doing or delivering is not their priority.

I've had the same experience at the big tech company I worked at.

I expressed these frustrations to upper management and the explanation I was given was that for many of these big companies, their goal is to grow their 1,000 sub-businesses to 10 million ARR businesses each. Growing these 10 million ARR units to 100 million ARR is much more difficult than going from 0 to 10 million, and so when they have a successful unit, they disproportionally reinvest that success into the poor performers (the 0-2 million ARR units).

This felt backwards and unfair to me as an engineer on the teams that worked hard to get to the 10 million mark. It really sucked seeing my team lose headcount or engineers to less successful and poorly designed/managed projects. But from a business perspective on the larger scale I see why they do it - I just think it creates a poor engineering culture and, in the long-term, a sub-par customer experience because velocity in product development slows when projects are de-invested or put into KTLO.

I kind of see your point at the macro level, but in our case we are both working in the same product, and contributing to the same bottom line. I see no strategic advantage on shifting resources from a high to a low performing team.

And of course the triple whammy happens when low quality software written by one team is handed over to a better team to fix it. I'm going through that right now. We have an upstream dependency that it's always causing all sorts of trouble. We've been told by leadership that if we notice issues we should go fix them ourselves rather than asking the other team to fix it. Go back to the incentives, what message are we sending the other team?

Frustrating dynamic. Something similar played out for me in a different industry, where a company doled out a bunch of different parts of a large project to different subcontractors. The subcontractor I was working at was apparently the only one that hit the dates and deliverables. So we got put on pause (aka defunded) while the other contractors were paid to catch up.

I never was sure why some of the unfinished work wasn't shifted to us, but the end result was the same as yours -- getting penalized for doing the demonstrably superior work.

is it common to roadmap features your team can’t deliver at their current size? that sounds like a problem.

also, the team that takes on the most work but does it poorly getting the promotions and bonuses also sounds like a problem.

both of those thing aren’t problems with developers though—theyre management problems.

i would interpret the moral as bad management leads to sub-optimal outcomes for developers. not advocating correctly for headcount, and not showcasing the high quality work your team does are literally what your manager should be doing.

>>[...] both of those thing aren’t problems with developers though—theyre management problems.

Sounds like the sister team had a better manager in some aspects of "managing" (e.g. managing the message up the chain) compared to the OP's manager who may have been great at facilitating (or minimizing meddling with) the high performing team but was less skilled in managing up.

agreed, i like your perspective. so hypothetically, what do you do here? ideally these managers should learn from one another.

should we send them to a tropical off-site?! joking

> is it common to roadmap features your team can’t deliver at their current size? that sounds like a problem.

Remember, we had the headcount last year, and we planned our roadmap accordingly (in fact my company tends to plan at least 1 year out to a certain level of detail). When they shifted the headcount, we just pushed the projects back. However this year came and we didn't have the people to deliver on our roadmap.

About your second part, I cannot say since I am not present in those meetings. I have always found my manager pretty good, but there are some things that are just outside his control.

This the type of bs that would make me start thinking about starting my own company.

I'm not brave enough to start my own company, but I'd definitely like to try a much smaller shop where people can't play politics so hard.

Can’t be promoted if you’re too good/irreplaceable.

It could be compensated at least by a pay raise.