Hacker News Reader

Comment by dasil003 | Hacker News Reader

> from a Snap survivor: ”So it’s frustrating; they expect us to still go out and win with these products, yet we have fewer resources.”

I don’t know what function this is it their manager is telling them, but this quote really reflects a bull market mentality that success is a function of resources applied without acknowledging the inefficiency of throwing money at a problem. People who want to be successful over the next 5 years really should be thinking in terms of how to operate efficiently and leverage what they do have. I think a lot of young VC-funded tech workers misunderstand how elastic resourcing actually can be in the software world, and how much past resourcing was speculative and incremental-not essential.

View on HN

Yeah. People don't appreciate how wasteful companies can be; being brutal about it, odds are a lot of those resources are unnecessary.

I say this as someone who was an unnecessary resource. In the early 10s I got hired into the "machine learning" division of a ~7000 person company, which was a local ML startup that had gotten acquired. After starting there, I quickly realized: the acquisition was just done by an exec/VP who decided the company needed a machine learning strategy, but had no idea what to actually do with the acquisition. I was there for about a year, and I couldn't really tell you what me, or anyone on my team, did that provided any value. We played around with Spark; we hired a few PhD students to mess around with some data, for no real reason; we had a dev who spent 6 months writing an insane purely functional CRUD HTTP framework. We ostensibly had some long-term project we were working on, but literally no functional software to show by the time I left. I was well-compensated and treated extremely well (fully stocked liquor cabinet and we start pouring drinks at 2pm on Friday, whoo!) yet probably the most miserable I had ever been in my professional life.

Anyway... I've found that my experience is not uncommon. Companies of 1000+ people have a lot of entire teams who are not really contributing anything to the business. During the boom times it's simply not worth it for management to spend their time trying to hunt down those teams, though; the salaries of 40 people is a drop in the bucket for a company of that size. Plus you never want to make cuts to your own headcount, as that reduces your power as a manager.

It's pretty reflective of the environment these employees operate in, though.

I'm an engineering manager at $BigCo. In my past life, I was a startup founder, so I'm no stranger to doing more with less. As a startup founder, the way I achieved efficiencies was a.) work on the right problems, or as close to the right problems as you can with the information available to you b.) don't do unnecessary work c.) look for efficiencies where the same piece of work can achieve multiple aims and d.) cut communication costs & overhead whenever possible.

At $BigCo, I generally have a set amount of work that my team has to deliver. I can provide input on priorities & goals, but if I, say, redirect product strategy into an approach that gets more users or offers a better user experience, the PM gets the credit, not me. (If they didn't, it's doubtful they would let me.). If I started a brand-new product that's beloved by users, it'll get killed by some executive that's threatened by its success. If I say "Let's not do X, it's not very important", and X is something that's been asked of my team by either execs or another team, I'm branded as uncooperative and will probably be managed out. Same if I cut communication loops and just do things without letting people know. OTOH, if I do lots of unnecessary work that is asked for by other people, and gussy it up so it seems more difficult than it actually is, all of my people get promoted and I look like a rising superstar.

I think this is the organizational variant of Gall's Law. ["A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system."]. Once a company has evolved processes and structure and an org chart, it cannot be made more efficient, because the inefficiency is coded into the structure of the organization. You have to throw away the company and start with a new, simpler company that does the same thing.

The best way to fix an under performing team is to reduce it's size. Split the team, move some people to another team, etc. It doesn't have to be about firing people and that actually should be a last resort. 2 is alright as a size. 3-4 is great. 5-7 can still work, anything over that is probably too large. You get all sorts of issues with big teams including increased communication and meeting overhead, scope creep (because those people need to be busy), too many captains on the ship and the resulting conflicts, etc. Most of that goes away if you split teams and allow them to focus. Small teams get more done faster. It's better to have 2 or 3 small teams than 1 large team. Don't have managers in the team, just tech leads. Product management is a cross team function. Not having a lot of team managers makes it easier to move people around as well. That's a good thing and you can adapt dynamically to changing circumstances and needs.

Big companies have a tendency to hire new people rather than to consider moving people that they have and trust already around because it's easier. Managers derive status from their team size and are protective of keeping their team members, especially the ones that get things done. This dynamic results in a lot of negative behavior and this weird dynamic of people being treated like generic resources that are literally hoarded. You get this ego driven empire building where the loudest managers get the biggest teams and the largest budgets.

This results in a lot of people ending up in the wrong place for the wrong reasons. And the resulting problems are fixed by hiring more people. If the company is big enough, you get teams literally engineering around other teams. And then inevitably after a few years somebody realizes that they have too many people and they start firing people. This actually makes the problem worse because the best people won't wait for that to happen and leave by themselves and of the ones that remain some get fired and the remaining people are probably demoralized.

Amen.

I work at a small shop, 3.5 devs. That presents limits to some extent.

And yet we were faster and more flexible than a company who had wads of cash thrown at them by some parent company who is now shutting them down.

I’d love to meet this half person

I'm overweight and count as 1.5 developers.

I gained 80 pounds last year and got a 50% raise!

The phrase "half-assed job" must have come from somewhere.

They're learning, transitioning out of a more customer facing role and training their replacement so skills are still getting developed and their time is split ;)

At small shops, very much a thing.

Ah yes the 0.5 dev, conjured up by the manager to push 4 devs work onto 3 realistic devs

a person being half- on the project or a contractor working 50% of the time is also possible.

Cynical nonsense. In a small shop, more likely that the manager codes but considers themself only 0.5 a dev because of overhead.

and that's one of the many reasons why project got delayed, manager gets optimistic and consider himself a 0.5, only to realise halfway that he is overwhelmed by meetings, and his superior is asking why is he even coding? He then simply leave it to the team, which is actually the best outcome in this situation. But like inflation, the initial estimation based on 3.5 dev is probably not gonna get revised because it has been committed to the boss or client.

The best thing a manager can do, is to support team when he can and NOT consider himself a resource, even if he does the coding.

We had the same discussions recently at a large big tech company. We just need couple.of planning meetings and 3-5 senior devs to launch, but nah never happens, security, privacy reviews, leadership presentations, etc, etc

Yup, it's not perfect but we get stuff out the door fast.

Other company, I assume they have the same stuff going on. Super ambitious ideas... not out the door.

I can just merge a branch all on my own most repositories if needed. Now that's not ideal but if you're disciplined, it's fast / effective.

There are times I wish we had more people / structure and such, but also times not.

The flip side of this is all the small, 3.5-dev shops that are fast and flexible—just so they can slam hard into a wall and tie themselves into permanent knots.

While many of the inefficiencies of larger companies are, indeed, highly wasteful, it is also true that some of those inefficiencies are to increase resilience. Looking around and seeing lots of fast, flexible small companies is, at least in part, survivorship bias.

I think your statement may be a bit broad here.

Let’s say upper management considers they need both feature A and B to win the market by end of quarter. But suddenly your team is half the number of people it used to be. You’re not realistically going to achieve more than you used to just through sheer elasticity. So either A or B will get done and it becomes a matter of prioritization.

Smaller companies and shops are nimble because they don’t have the burden of the past, red tape and standards that exist at scale. For engineering orgs the size of Snap’s things take longer and having more people very often does solve the velocity problem.

Realistic outcome: management tells the team they still need to achieve the same work with half the people through heroism. The remaining members notice they're expected to do twice the work under a lot more stress, in a workplace that suffers the typical post-layoff low morale, and they quit themselves. Feature B doesn't get done, feature A gets rolled out by a bunch of enthused fresh grads and is buggy and unstable.

> For engineering orgs the size of Snap’s things take longer and having more people very often does solve the velocity problem

Your comment is totally fair. I will say though, that the impact of having more people is a function of how independently they can be deployed. One of the biggest challenges for hypergrowth companies is how to decouple things as they scale to keep people productive without drowning the org in communication overhead. Brooks' Law looms large in single product companies when they start to hit 4-figure engineering team sizes.

This is so well said.

Reply on news.ycombinator.com