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.
The magic of small engineering teams
71–80 of 161 posts
Re: The magic of small engineering teams
#72Re: The magic of small engineering teams
#73Counterpoint: 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).
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
#74Counterpoint: 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…
Re: The magic of small engineering teams
#75Corporations 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.
Re: The magic of small engineering teams
#76Earlier 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.
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
#77Re: The magic of small engineering teams
#78Counterpoint: 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).
Re: The magic of small engineering teams
#79Counterpoint: 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).
Re: The magic of small engineering teams
#80Buried lede: software engineering doesn’t scale.
Also I think with open source it has scaled. I don't have to reinvent curl