Live data from Hacker News

The magic of small engineering teams

newsletter.posthog.com

71–80 of 161 posts

Re: The magic of small engineering teams

#71

Earlier quoted context omitted.

I think this is all too common due to a small few who take advantage which leads to the construction of barriers to prevent abuse. This isn't limited to large orgs -- it's everywhere in society. I suspect accountability without authority might not be as accurate as one might seem when there exists middle management. You might be accountable but your boss probably is more so, thus the reluctance in giving full autonom…

If barriers harm more than abuse then abuse should be accepted.

Measuring the losses due to abuse is much easier than measuring the cost of bureaucracy.

Re: The magic of small engineering teams

#73
post #2

Counterpoint: Being on a small team in a large organization sucks. In a large org, small teams have no weight. Actually, we have wait - we have to wait for everything: devops resources, marketing resources, even infosec resources. We are too small to notice, not important enough to get quick attention (never mind that our small team's product is profitable).

That's when you need an advocate in upper management. You aren't going to get shit for funding even if your PM is well liked and your product idea is well thought out and solid. Someone in the circle of the one who signs the checks needs to be able to talk about your product like it's the next best thing. They also need to have the connections with their counterpart at the customer's offices to be able to sell the idea to their boss, "I've heard that company X is working on some new development for Y. If we invest, we could get first dibs on using it in our flagship product." Good ideas need to flow up to be given money. Likewise, Ideas that flow down almost always end up being a boondoggle, "Let's make a box that does X, Y, and Z, get the engineers on that right now!". If your good idea doesn't have an advocate, it will die on the vine and someone else will do it instead. What's the point of spending a bunch of money investing in an idea when a competitor got customers to invest in R&D for the same idea for free? Unfortunately, your advocate is probably not going to be a technical person. They won't understand the bits and bytes that make it novel, they need a soundbite that they can easily regurgitate ("We can shrink the current production design to draw X% less resources for the same or less money.")

You could be the smartest guy at the company, have the most well rounded team, have a PM that orchestrates people like a symphony conductor, and have a huge idea that would make absolute bank for the company but your idea won't matter for shit if you can't sell it.

Re: The magic of small engineering teams

#74
post #2

Counterpoint: Being on a small team in a large organization sucks. In a large org, small teams have no weight. Actually, we have wait - we have to wait for everything: devops resources, marketing resources, even infosec resources. We are too small to notice, not important enough to get quick attention (never mind that our small team's product is profitable).

One of the most interesting discussions I've had around this was at a small company who mass-hired a bunch of people from a big company. We went round and round in circles for a while because of issues similar to what you're describing. I ran a small 4-6 person hardware team (softly blurry on the edges) and the new people wanted significant amounts of design and documentation review as well as financial oversight. We…

I noticed something similar on a project I was on. I was given the task to supervise external contractors but given no authority to tell them how to do things. I basically had to convince them with arguments. Well predictably it's pretty hard to convince somebody that they are wrong but it's nearly impossible if it will also cut the project time in half which means it will cut the money for them in half. So naturally there was quickly a quarrel because they wanted to keep doing things badly and it was my assigned job to prevent exactly that. I was eventually overruled by my own management though because I can't compete with several external project managers whose entire job it is to talk their way into more money. They were willing to outright lie and there was no incentive to believe me vs. believing the supposed expert contractors.

Re: The magic of small engineering teams

#75

Corporations are mostly just job programs. Most companies do not actually need anywhere near the number of people they have employed to function. The reasons why small teams work is because the number of communication channels go down, and you spend less time simply talking about the work and actually doing the work.

This is not true. If the people weren’t providing some positive ROI then the execs would be drooling over the money saved from cutting them.

Where do you think all the heads to chop came from for all the publicized layoffs in tech these past couple of years?

Re: The magic of small engineering teams

#76

Earlier quoted context omitted.

If barriers harm more than abuse then abuse should be accepted.

Measuring the losses due to abuse is much easier than measuring the cost of bureaucracy.

It's precisely the other way around. Cost of bureaucracy is easy to measure, abuse is not measurable (only caught abuse). Nevertheless, the point is that it is difficult to compare a known cost to an unknown cost, so that still stands.

People are risk averse, so a known cost is preferable, even if expectedly higher than dealing with abuse. This is in part why insurance is so profitable.

Re: The magic of small engineering teams

#78
post #2

Counterpoint: Being on a small team in a large organization sucks. In a large org, small teams have no weight. Actually, we have wait - we have to wait for everything: devops resources, marketing resources, even infosec resources. We are too small to notice, not important enough to get quick attention (never mind that our small team's product is profitable).

But the advantage to being blocked all the time is that you can then go find other places to add value. Having impact outside of your small team is huge when it comes to performance reviews and promotions, especially if it’s self driven. But you can’t do that kind of stuff if you have other high priority work in your teams backlog that you can freely pick up.

Re: The magic of small engineering teams

#79
post #2

Counterpoint: Being on a small team in a large organization sucks. In a large org, small teams have no weight. Actually, we have wait - we have to wait for everything: devops resources, marketing resources, even infosec resources. We are too small to notice, not important enough to get quick attention (never mind that our small team's product is profitable).

I think the primary idea of a small team is that it is self-sufficient and avoids the N^2 problem associated with everyone talking to everyone.
Post reply on HN