korrents

team size

How many people a thing needs, and what the extra ones cost: headcount, coordination, and the small-team claim.

What people on korrents have said about team size, newest first — 12 positions from 7 people.

FilterEveryone, all time
Who Everyone DHDavid Heinemeier Hansson 5 NFNat Friedman 2 GOGergely Orosz 1 JZJulie Zhuo 1 MZMario Zechner 1 PGPaul Graham 1 PDPavel Durov 1
When All time Past 1 yearPast 3 yearsPast 5 years
  1. NF

    Nat Friedman quoted

    Our readingSmaller teams are better

    Their wordsSmaller teams are better Faster decisions, fewer meetings, more fun No need to chop up work for political reasons

    ↗Nat Friedmannat.org

    Interesting
  3. NF

    Nat Friedman quoted

    Our readingLarge engineering projects are more soluble in IQ than they appear, and many tech companies are overstaffed

    Their wordsLarge-scale engineering projects are more soluble in IQ than they appear Many tech companies are 2-10x overstaffed

    ↗Nat Friedmannat.org

    Interesting
  4. 1 day earlier
  5. GO

    Gergely Orosz quoted

    Our readingA healthy on-call rotation needs at least six engineers for every alert to get an engineer's full attention.

    Their wordsa healthy oncall schedule needs 6+ engineers if every alert is to be taken seriously by an engineer whose main focus is oncall and systems stability.

    ↗The Pulse: Meta wanted to reduce teams by 60% because of AIblog.pragmaticengineer.com

    Interesting
  6. 6 weeks earlier
  7. DH

    David Heinemeier Hansson quoted

    Our readingThe competitive threat to a small software company is a team of two or four working under the same constraints, never the behemoth.

    Their wordsI'm worried, and still am, about a team of two, about a team of four, because they will produce software that's competitive with ours because it comes out of the same constraints. And therefore, our threat doesn't come from the behemoth.

    ↗DHH: How to Build a Profitable Company Without Losing Controlyoutube.com 1st of 15 in this recording

    Interesting
  8. 4 months earlier
  9. MZ

    Mario Zechner quoted

    Our readingTwo people with agents can reach enterprise-grade codebase complexity in weeks -- what took organisations years, and they at least adapted to it as it grew.

    Their wordsAnd organizations have super high pain tolerance. But human-made enterprise codebases take years to get there. The organization slowly evolves along with the complexity in a demented kind of synergy and learns how to deal with it. With agents and a team of 2 humans, you can get to that complexity within weeks.

    ↗Thoughts on slowing the fuck downmariozechner.at

    Interesting
  10. 6 months earlier
  11. PD

    Pavel Durov quoted

    Our readingHeadcount does not translate into product quality, and often the opposite: too many people spend their time coordinating, and the idle ones demotivate the rest.

    Their wordsWell, what we realized really early is that quantity of employees doesn't translate the quality of the product they produce. In many cases, it's the opposite. If you have too many people, they have to coordinate their efforts, constantly communicate, and 90% of their time will be spent on coordinating the small pieces of work they're responsible for between each other.

    ↗Pavel Durov: Telegram, Freedom, Censorship, Money, Power & Human Nature | Lex Fridman Podcast #482youtube.com 9th of 28 in this recording

    Interesting
  12. 3 months earlier
  13. DH

    David Heinemeier Hansson quoted

    Our readingMicroservices for a team of twenty on half a million lines of code is idiotic: the first rule of distributed programming is do not distribute your programming.

    Their wordsWhen you're at Netflix scale, when you apply that pattern to a team of 20 programmers working on a code base of half a million lines of code, you're an idiot. You just don't need to turn method invocations into network calls. It is the first rule of distributed programming. Do not distribute your programming.

    ↗DHH: Future of Programming, AI, Ruby on Rails, Productivity & Parenting | Lex Fridman Podcast #474youtube.com 15th of 36 in this recording

    Interesting
  15. DH

    David Heinemeier Hansson quoted

    Our readingA thousand programmers build the kind of software a thousand people build; Basecamp could never come out of that, and the breakthroughs come from individuals and tiny teams.

    Their wordsYou cannot produce the kind of software that Basecamp is with a team of a thousand people. You will build the kind of software that a thousand people builds. And that's not the same thing at all.

    ↗DHH: Future of Programming, AI, Ruby on Rails, Productivity & Parenting | Lex Fridman Podcast #474youtube.com 20th of 36 in this recording

    Interesting
  17. DH

    David Heinemeier Hansson quoted

    Our readingThe default team is two people, one programmer and one designer, on one feature; at that size you can just do instead of plan.

    Their wordsour default team size is two. One programmer, one designer, one feature. When you're operating at that level of scale, you don't need sophistication. You don't need advanced methodologies.

    ↗DHH: Future of Programming, AI, Ruby on Rails, Productivity & Parenting | Lex Fridman Podcast #474youtube.com 21st of 36 in this recording

    design

    Interesting
  19. DH

    David Heinemeier Hansson quoted

    Our readingThe way to stay small is never to take other people's money: the moment you do, they want the largest return, and the enterprise playbook follows.

    Their wordsBecause the problem isn't just venture capital, it's other people's money. Once you take other people's money, completely understandably, they want a return and they would prefer to have the largest return possible.

    ↗DHH: Future of Programming, AI, Ruby on Rails, Productivity & Parenting | Lex Fridman Podcast #474youtube.com 22nd of 36 in this recording

    startupsventure capital

    Interesting
  20. 4 months earlier
  21. JZ

    Julie Zhuo quoted

    Our readingAI favours tiny teams of high-agency individual contributors with blurred roles, and the coordinating manager is not needed until it is time to polish.

    Their wordsWelcome to the era of AI-native companies, where individual contributors (ICs) reign supreme.

    ↗The Death of Product Development as We Know itlg.substack.com

    Interesting
  22. 22 years earlier
  23. PG

    Paul Graham quoted

    Our readingBig companies have software designed by committee to avoid disasters, so a startup wins design wars by having the same people design and implement the product.

    Their wordsThe place to fight design wars is in new markets, where no one has yet managed to establish any fortifications. That's where you can win big by taking the bold approach to design, and having the same people both design and implement the product.

    ↗Hackers and Painterspaulgraham.com

    startupsdesign

    Interesting