Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The magic of small engineering teams

newsletter.posthog.com

Post reply on HN
Print view View original

81–90 of 161 posts

Re: The magic of small engineering teams

#81

Post by osigurdson »

tonyarkles wrote: post #4
psim1 wrote: 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…

This is a very common problem in many orgs. Spending time (adding meetings, exploring various options, etc.) is completely fine while spending money is a huge deal because of the emotional connection to money that many people seem to have.

Imagine, holding a 2 hour, 10 person meeting to decide if an additional one time $1000 cloud expenditure is warranted. Yet, this happens all the time. I can assure you, that this is not how shareholders or customers want you to spend your time.

Re: The magic of small engineering teams

#82

Post by thwarted »

goosejuice wrote: post #25
al_borland wrote: post #7

Earlier quoted context omitted.

This kind of stuff drives me nuts. I just spent 8 months fighting to get $150 for something. This should have just been taken out of some petty cash fund, but instead I wasted a ton of my time, and others, fighting to get it from the proper source. This cost the organization thousands of dollars in lost time.

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…

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.

Tragedy of the Commons Ruins Everything Around Me.

Those who act selfishly poison the well for everyone.

Re: The magic of small engineering teams

#83

Post by osigurdson »

r0ze-at-hn wrote: post #13

The author is writing about the common story of how to grow and scale. Each team gets a product, spinning off teams, etc. What if like most products there is a ramp up period where you need a full team (or teams) and then a few years later the product needs at most a fraction of the people to maintain the product? All of these people are going to "do stuff" because they are paid to do stuff further increasing the mai…

I don't think it is really like that. Growing a code base at first is very fast, but then slows down entirely due to the human "context window" being limited. So unfortunately, you need more people to maintain a million line code base than a 1000 line one.

Re: The magic of small engineering teams

#84

Post by kortilla »

bdcravens wrote: post #75
kortilla wrote: post #39

Earlier quoted context omitted.

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?

Expected ROI.

Do you know what a jobs program is? I think a lot of confusion comes from people not understanding that a role that currently costs more than in brings in is absolutely not the same thing as a jobs program.

A jobs program is designed to just keep people employed at a loss by design. No expectation of a path to ever making money. The TSA is an example of a jobs program.

Re: The magic of small engineering teams

#85

Post by anal_reactor »

zeroonetwothree wrote: post #59
hdhshdhshdjd wrote: post #5

I think the inflection point between “startup” and “bureaucracy” (which is not a bad word, just a term for organizing people) is role specialization. Early stage everybody wears 10 hats, work is distributed and prioritized on a day to day basis. Once you have dedicated people or teams for task domains then the whole thing shifts to having a need for bureaucracy. You can slice the number of pizzas anyway you want, but…

I think “this isn’t my job” is generally a bad mentality (sure there are some times it’s ok, but those are like 1% of the actual times it’s used)

There's a limited number of people I can get to know within a unit of time. This means there's a limited number of people I can care about. If there's my coworker Dave who has three children, two dogs, depression, and talks to me on lunch break about all of these, and asks me to take over his task, I can do that. If a random guy I've never seen before comes to me and wants something, I'll naturally look for a way to get him to fuck off

Re: The magic of small engineering teams

#86

Post by fragmede »

zeroonetwothree wrote: post #59
hdhshdhshdjd wrote: post #5

I think the inflection point between “startup” and “bureaucracy” (which is not a bad word, just a term for organizing people) is role specialization. Early stage everybody wears 10 hats, work is distributed and prioritized on a day to day basis. Once you have dedicated people or teams for task domains then the whole thing shifts to having a need for bureaucracy. You can slice the number of pizzas anyway you want, but…

I think “this isn’t my job” is generally a bad mentality (sure there are some times it’s ok, but those are like 1% of the actual times it’s used)

It depends on why it isn't my job. If I have the ability and the capability and the time to do it and probably a few other things, then it's bad. But framed as a specialization inside a giant company, where it's not my job so if I do it, I'll do a bad job and make mistakes and cause more work for you and me, and end up being a -10x engineer, please tell me it's not your job.

Re: The magic of small engineering teams

#87

Post by 1312214 »

Nathanba wrote: post #74
tonyarkles wrote: post #4

Earlier quoted context omitted.

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…

Had a similar thing. Ex Company hired outside agency in order to deliver big feature on time. Lead guys in agency were sweet talkers and they were lying to C level executives(they believed them because of buzz wording). Agency overcomplicated the system with microservices, kubernetes, etc. Everything ended up more complicated and slower. Whenever you tried to suggest something they would just speak in private with CTO and you would get shushed. Half of our original team was moved to other projects because agency "new better". I quit and it was best decision

Re: The magic of small engineering teams

#88

Post by vasco »

r0ze-at-hn wrote: post #13

The author is writing about the common story of how to grow and scale. Each team gets a product, spinning off teams, etc. What if like most products there is a ramp up period where you need a full team (or teams) and then a few years later the product needs at most a fraction of the people to maintain the product? All of these people are going to "do stuff" because they are paid to do stuff further increasing the mai…

You declare things under maintenance mode and you stop work on them other than to solve incidents or implement the postmortem improvements.

If you do this all the time for "finished" bits and instill a culture of "getting to done" in your engineering, it'll just be normal every quarter to move some stuff into maintenance and free up time.

Re: The magic of small engineering teams

#89

Post by bogdan-lab »

At large scale, when your company developed a significant tech debt (~1mln lines of code), you will especially value people who understand what is going on in all that code. I am afraid, that with smaller teams "renewing teams" will be too quick for new joiners to grasp what is going on. I mean, everyone from "old" team will leave before newcomers are ready to own the product.
Post reply on HN