17 ms·

The magic of small engineering teams

266 points by andyjohnson0 2y ago

psim1 2y ago
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).
- hobs 2y ago
  Also a fundamental property of small teams (which can be good) is you can only commit to so much. You absolutely know you wont ever build a lasting bridge with a six person team, but you could ford a river. This type of stuff is ok when you are in startup mode but doing this long term at big companies creates a lot of existential risk that could be mitigated by better planning. This is a tradeoff some people make knowingly (like the posthog post clearly lays out) but as usual this "2 pizza team" is cargo culted way too hard. In many cases I see the product folks with the same vision regardless of the team sizes or org fit.
  - ghaff 2y ago
    Put another way there is only so much you can do with a small team—and a small company. Things change as you grow. You can do more/bigger things but efficiency almost certainly takes a hit.
- tonyarkles 2y ago
  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 needed $40 worth of solder and connectors and had to wait a week for PO approval as well as demonstrate that we had gotten multiple quotes... even though there was just a store down the block that sold exactly what we needed. Anyway, after a month or two of this I started catching significant flak because my team was nowhere near as productive as it used to be. Complaining about slow POs was met with "maybe you should plan better". Complaining about design reviews for one-off boards that would go from idea-to-problem solved was met with "you're engineers, you need to document your work". It was painful and I came very close to resigning. What ultimately worked, though, was figuring out a catch phrase that spoke the language of the new people: "accountability without authority". This ruffled some feathers but once I repeated "you are trying to hold me accountable for delivering a $500,000 project on time but are not giving me authority to buy $40 worth of stuff to execute on that" enough times it finally got through and the system started to change. But man did it suck for a while.
  - al_borland 2y ago
    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.
    - goosejuice 2y ago
      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 autonomy. They of course won't be able to take credit in that case either :). Perhaps an overly cynical view I admit.
      - vbezhenar 2y ago
        If barriers harm more than abuse then abuse should be accepted.
        loupol 2y ago
        Reminds me of that bits about money blogpost title : "The optimal amount of fraud is non-zero"
        Cyphase 2y ago
        https://www.bitsaboutmoney.com/archive/optimal-amount-of-fraud/ https://www.bitsaboutmoney.com/archive/optimal-amount-of-fra... https://news.ycombinator.com/item?id=32701913 https://news.ycombinator.com/item?id=32701913
        OJFord 2y ago
        Matt Levine has a recurring bit on this in Money Stuff too, adjusting the crime/fraud/risk dial back and forth as companies decide to do more or less compliance.
- dheera 2y ago
  > not important enough to get quick attention If you are essential to the company, it is on the company to give you the resources you ask for, or they are asses. If you have to waste time fighting for them, to the point where work can't get done, that is their problem. If you are non-essential to the company, then it is on you to start looking for a place where you will be essential, either internally or externally.
- crtified 2y ago
  This reminds me of a situation which I'll label "satellite office syndrome" - which is where a company has a large/dominant Head Office, and smaller regional offices which are in a permanent state of playing second-fiddle in terms of funding, attention, respect and company culture.
  - kjellsbells 2y ago
    This is as true with products as with locations. For example, the people doing S3 at Amazon get everything they need, because that is a blockbuster product...and the people doing, oh I dont know, Greengrass IoT are waayyy down the totem pole even though it might be a perfectly profitable product. Large orgs tend to have a Roman Empire feel to them for most of the people, most of the time. You're stuck out on the edge of the empire, minding Hadrian's Wall, proud to be a Roman but also far, far away from any influence over or interest from the Emperor. If you are lucky they leave you alone. Occasionally a missive arrives from Rome that you have to decipher and implement no matter whether it makes sense or not. Fun times.
    - com 2y ago
      I thought that metaphor would go in a different direction, tbh. I was thinking “praetorian guards”, “imperial decline”, “decadence”, “barbariand resettling inside the limes” etc.
- wildzzz 2y ago
  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.
- baron816 2y ago
  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.
- osigurdson 2y ago
  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.
  - seadan83 2y ago
    N choose two, not N^2. The latter double counts and also counts people communicating with themselves. For example, with 2 people, it is not 4 paths of communication, but just 1. N choose two is n*(n-1)/2, which yields the right answer In asymptotic analysis, they are the same. Except, that analysis does not make sense, asymptotic refers to the growth of the function as values approach effectively infinite
- deleted 2y ago
  [deleted]
hdhshdhshdjd 2y ago
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 imho once people have a “this is/isn’t my job” mentality (which again, is not a bad thing), you really need to focus on role boundaries and coordination. But the “startup” part is in the rear view.
- zeroonetwothree 2y ago
  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)
  - hdhshdhshdjd 2y ago
    I mean this in the broad sense: like asking somebody in the sales department to lead a mission-critical database migration. That is in no way their job.
  - anal_reactor 2y ago
    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
  - fragmede 2y ago
    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.
shishy 2y ago
Is this similar to single threaded owner (sto) models? I'm curious how they handle things like career management and promotions but this structure overall seems great
angarg12 2y ago
> Startups ship more per person than big companies – everyone knows this. But how do you retain that advantage as you scale? Our answer is small teams > Right now we're 47 people I'm sorry, but you haven't solved scaling small teams.
- TulliusCicero 2y ago
  Yeah, felt like a bit of a rug pull. At that size, you've scaled only slightly; everyone in the company probably still knows each other on some level. But how do you maintain small team effectiveness in a company of hundreds, if not thousands?
ttyyzz 2y ago
I have to disagree with the "2 to 6 people" - even for small projects I feel like 4-6 people is great. This way you can ensure that everyone has a “tandem” and e.g. It's not just a frontend developer doing some mischief that someone has to clean up afterwards :D
habitue 2y ago
This is interesting, because at 47 people they're in transitional scaling. Like they've had to solve "too many teams for the CTO to manage directly" but not "too many teams to align effectively". At 15 strong self-directed teams, you can have a few teams focused on the high level directives, and a few entropy repair teams that mostly self-manage. The way to think about it is maybe like homeostasis. Self-directed product teams will implement new features, fix bugs, and generally keep the thing on track, but the efficiency drops off as the feedback mechanisms of talking to customers reaches equilibrium. To mix metaphors, a leadership team creates a kind of current flow in that system. When you're small you can go to each of those teams and ensure that current flow is happening. But at a larger size, that doesn't work. You have to engineer and carefully craft the feedback mechanisms the teams are working off of to induce that current. This is a hard problem, but it's where things like minimum attrition policies, OKRs, etc spring from: leadership trying to have a policy that induces current.
r0ze-at-hn 2y ago
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 maintenance burden. You run head first into the common problem of: "I have 1000 engineers and I can't get anything done!" In the worst case the CEO solves this by doing lay offs. Been thinking about this problem for over a decade, making effective engineering organizations that can not only grow, but change shape is difficult, but can also be very rewarding when done successfully.
- marcosdumay 2y ago
  I dunno. The obvious answer is that then you make another product. and another, and another. But very few companies are able to do this for some reason.
  - wavemode 2y ago
    Creating products is very easy. Creating products that generate a profit is very hard. If a company could do so on demand, it would be an infinite money glitch.
- osigurdson 2y ago
  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.
- vasco 2y ago
  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.
whoknowsidont 2y ago
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.
- paulryanrogers 2y ago
  Or perhaps corporations grow large because they serve diverse needs. Much like users only need 10% of Microsoft Word, yet many cohorts often need a different 10% slice. Or we lack anti-trust controls, so rent seekers are soaking up markets. Maybe a combination of all three.
  - whoknowsidont 2y ago
    >Maybe a combination of all three. Likely. How big each "slice" is would be good to know. I wish someone would study it in depth, if it's even possible to fairly analyze. I don't necessarily think your analogy with MS word is a fair or correct one, FWIW, only because once you build something the functionality is able to be distributed and replicated. Employees require active up keep in a way that software really doesn't.
- kortilla 2y ago
  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.
  - rqtwteye 2y ago
    I don’t think so. Unless you get super high up, your pay increases proportionally to people under you. The next problem is that once you start cutting, you actually have to organize and manage. That’s way more difficult than saying “ I have hired x people”. I have been in countless discussions where management offered more people but whenever I told them the real problem is the process or another department not doing their job, I got silence.
malfist 2y ago
The whole section on managers rubbed me the wrong way. Team leads aren't managers and thus aren't responsible for onboarding, not communicating up the chain about perfomance, but is Responsible for performance of individuals on the team. And the phrasing about managers mostly care about happiness and team leads don't, makes me think this place might be very toxic to work for. Reeks of "brilliant jerk" acceptance and accountability without authority. It also feels rich to have a 47 person company tell you they've figured out the secret sauce of people management and team formation.
drewcoo 2y ago
> Startups ship more per person than big companies – everyone knows this. Startups can quickly change alignment to make the company work. They can throw more spaghetti at the wall to see when it's done. > But how do you retain that advantage as you scale? Once the company figures out what works, you'll want to put people and processes in place to keep it working. That means bureaucracy. That slows change. Intentionally. In big commercial kitchens no one throws spaghetti at the wall. That's waste.
arjunlol 2y ago
This was particularly bad at Meta pre-efficiency push Zuck. There was huge bloat that was counterproductive. Empire builders were incentivized by promotions based on the size of their orgs. One thing the article didn't mention is how crucial it is for a team to have focus and to ruthlessly prioritize. It's easier for bigger teams to fall into the trap of doing "busy work" and people fighting for scope on their performance reviews. This is the worst possible outcome for company and employee where you have work driven by optics vs value.
- nextworddev 2y ago
  Empire building has gotten rejuvenated recently at faang due to people politicking to get the fancy AI projects
  - deleted 2y ago
    [deleted]
  - deleted 2y ago
    [deleted]
- kridsdale3 2y ago
  I quit meta in large part for this reason, right before the push. My friends who stayed said the workload was hell, but I wonder if I would have experienced less manager / director incompetence. P Thiel, in 0-1 which I just started, says if you find yourself in an org where people spend more time building artifacts of showing progress, than progressing something, quit.
goosejuice 2y ago
but it has worked best for our company with these rules Sharing is good, but as others have pointed out, folks publishing such things could use a bit more intellectual humility. At this point perhaps authors just expect others read it as opinionated anecdotes. Typical thought leader dogma aside, using pizza as a metaphor for team size has always been silly to meaningless.
- mathgeek 2y ago
  > Typical thought leader dogma aside, using pizza as a metaphor for team size has always been silly to meaningless. An easy way to see it fall apart is to imagine a team that each eats 3-4 slices of pizza, or a team that only eats one slice each.
  - verve_rat 2y ago
    Yup, in NZ a two pizza team would average out to about three people I think. Are US pizzas giant?
    - skywhopper 2y ago
      We have lots of sizes of pizza. Though I think the type they mean are the sort ordered from chain places for large groups, so usually 14-16 inches (35-40cm) diameter cut into 8-12 slices.
    - OJFord 2y ago
      I think it's meant to be an 'order some pizzas, everyone grabs a slice' sort of situation, not 'everyone is hungry and has a proper meal'.
      - mathgeek 2y ago
        If this were true, a two-pizza team would be 12-24 people (assuming a pizza gets sliced somewhere from 6-12 slices).
        2y ago
binary132 2y ago
Buried lede: software engineering doesn’t scale.
- 01HNNWZ0MV43FF 2y ago
  It'll be funny if it ever does. AI replacing programmers is funny, AI replacing managers is hilarity. Also I think with open source it has scaled. I don't have to reinvent curl
  - binary132 2y ago
    curl and git are amazing but they aren’t skyscrapers. Building a skyscraper, space shuttle, or integrated circuit is hard to organize even once, let alone to abstract over the process of organizing and building it so that it can be reproduced. I don’t think that problem is solved at all. And it’s not at all as simple as “just take the open source legos and slap a few of them together!”
    - defrost 2y ago
      > Building a skyscraper [...] is hard to organize even once, let alone to abstract over the process of organizing and building it so that it can be reproduced. I don’t think that problem is solved at all. Hong Kong has over 9,000 high-rise buildings, of which over 4,000 are skyscrapers standing taller than 100 m (328 ft) with 554 buildings above 150 m (492 ft). ~ https://en.wikipedia.org/wiki/List_of_tallest_buildings_in_Hong_Kong https://en.wikipedia.org/wiki/List_of_tallest_buildings_in_H... A fair number of the Hong Kong skyscrapers appear to be cookie cutter | symmetry (reflection &| rotation) patterns. Elsewhere: As of September 2023, fourteen cities in the world have more than 100 skyscrapers that are 150 m (492 ft) or taller ~ https://en.wikipedia.org/wiki/Skyscraper https://en.wikipedia.org/wiki/Skyscraper I'm going to suggest that high rise engineers have some pretty solid skyscraper templates today. The greater challenge likely comes from architects and investors wanting unique 'statement' designs.
      - seadan83 2y ago
swader999 2y ago
4-6 is ideal, over 6 people and the communication and coordination overhead starts to cost too much.
skywhopper 2y ago
God, I hate the pizza as a unit of team size. It tells me nothing.
- d3m0t3p 2y ago
  isn't a pizza for one ?
- maccard 2y ago
  It’s an abstract measure that is somewhere between 2 and 10 people. It’s deliberately not supposed to be prescriptive
  - skywhopper 2y ago
    This is what I’m saying. “Between 2 and 10” is useless guidance.
    - maccard 2y ago
      I don’t think it is, at all. It’s telling you to keep teams small enough that you can manage them and have them all in one meeting
      - seadan83 2y ago
        And secondly, do not need to fill out an elaborate expense report for buying lunch. At the time of two pizzas, Anazon circa 2008, that would have been a sub $50 order.
  - seadan83 2y ago
    It is one large pizza, 8 slices, that is 3 to 4 people. Yes, some people can eat more or less. If you had 10 people, you could order 2 larges but that is going to be a treat or a snack, not something that will be welcome if that is a lunch meeting.
Scubabear68 2y ago
A 47 person company with 15 teams sounds like a nightmare to me.
jWhick 2y ago
man posthog is one of the shittiest companies there is out there.
- mp05 2y ago
  ...go on? I've been using Posthog for a few months now and it's been a nice experience.
  - batshit_beaver 2y ago
    Working for them seems far less pleasant.
siliconc0w 2y ago
4-6 is reasonable but for I feel 5-8 is a bit more sustainable to add some redundancy- though that should include a technical lead who also serves as the manager (50-50) and ideally a product/program person who can maybe float between teams. It's also important that everyone is using the same standardized toolkit and shared infrastructure so each team doesn't invent their own ways of working or tooling. Some flexibility and experimentation is good but it should be clearly segmented until it's clear the innovations are worth the adoption and maintenance costs of both the 'new' and now 'legacy' system.
mp05 2y ago
>> Small teams are effectively one-pizza teams, as opposed to the two-pizza teams idea popularized by Amazon. They don't know how much pizza I can throw down, especially when the company is paying.
electrodank 2y ago
[flagged]
esafak 2y ago
Left unsaid is that smaller teams mean more hierarchy. You're not getting something for nothing.
osigurdson 2y ago
I never really understood the "pizza" metric. Why not just state the range instead?. Two pizzas can "feed" a lot of people (perhaps 16 - 20 even) if they aren't very hungry, aren't very big or aren't very young.
- yen223 2y ago
  Numbers are hard to remember, but pizza is easy to remember
  - osigurdson 2y ago
    I tried hiring a 2 pizza team once. It was very quick, as all hiring was wrapped up in about 45 minutes. It was also very inexpensive. But, they just sat there, doing nothing. I'm done with 2 pizza teams.
- seadan83 2y ago
  I joked that I was a half pizza team on my own. The commute had me riding 25 miles per day on bike, I don't eat breakfast and only a light dinner -> lunch was easily 4 slices of pizza. In seriousness, pizza is not a bad measure since it means basically 3 to 4 people per pizza. Thus two pizzas is 6 to 8. 2 slices is usually assumed to be the serving size. 20 people is not even one slice per person
bogdan-lab 2y ago
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.
flappyeagle 2y ago
For a product like PostHog this might make sense. But YMMV. Their product is a collection of micro products which is pretty unusually especially for a company at their stage and size
- The_Colonel 2y ago
  That's an important context which kinda invalidates the value of this article. Scaling the number of independent products is almost trivially easy. What's difficult is scaling one product to a large size, since there breaking up teams doesn't achieve much on its own.
greatest69 2y ago
Small engineering teams are usually because there is no architecture team and the organization is “not yet mature enough” or their IT management sucks. Also this is marketing for consultants.
xorcist 2y ago
This could be put more succinct: Trivial problems are trivial. Of course you can keep splitting your teams when you are delivering a well defined product to customers. You could probably also have not split those teams. 50 people is trivial to manage, you could all meet in a room, should you have kept them geographically close. You may even have succeeded despite neutering those teams into triviality. You simply don't know. Try doing something even slightly more complicated: Build a bridge. Or run a hospital. Or even a pension fund. Or just a software company with a lot of products. Those nice trim teams would quickly run into the brick wall of human communication. That's the tough part of any organization. And we as a society needs to organize on large scale to get the important things done, unfortunately. Getting the easy things done is not enough.
crop_rotation 2y ago
Small teams work very very well if the team is full of competent people. Such a small team will execute much faster. The problem is that if you need to do more work at some point a small team won't be sufficient and you will end up hiring more. And as you hire more you will inevitably have quality dilution. Both communication in large team size and hiring issues make large teams much less effective.
- exe34 2y ago
  Communication is the productivity killer. Where before you could have three people spend 95% of their time doing and 5% coordinating, as the number of people goes up, the amount of coordination blows up geometrically. you spend most of your time discussing and very little actually gets done.
- dnissley 2y ago
  Oncall health is another good reason to increase team size -- having a 4 person rotation where everyone is oncall once a month is much less sustainable than an 8 person rotation where you're oncall once every two months
rco8786 2y ago
I'm a fan of small teams also - but slowing down as the company scales is unavoidable. > Startups ship more per person than big companies – everyone knows this. But how do you retain that advantage as you scale? You can't! Not really. If you could, we would see companies doing it but...we don't (barring some yet undiscovered engineering process). Everything you ship, by definition, has an ongoing maintenance cost. The more you ship, the higher your maintenance burden. Over years, this grows and grows. Output (as defined by "products shipped") per engineer must go down, because more and more engineers must be dedicated to maintenance work. Now, we've gotten really good at disguising maintenance work as product work/shipping things. But it's not reality. Even this post makes this mistake by referring to "data warehouse" and "analytics" as "products". But customers don't care about your data warehouse or your job pipeline. > Right now, for example, we're in the process of scaling support by moving our support engineers out of the customer success team and into a new customer comms team. This is not product work. This is maintenance, and is a literal example of the type of thing that larger companies have to do just to maintain their existing products and contributes to lower product output per engineer.
- generic92034 2y ago
  > Even this post makes this mistake by referring to "data warehouse" and "analytics" as "products". But customers don't care about your data warehouse or your job pipeline. Depending on the part of the software industry you are in, customers might care very much about data warehouse or analytics products. Particularly, those products are highly important in the ERP area.
  - rco8786 2y ago
    For sure if those happen to be your actual products, but that's not the impression I got from reading this particular post. (Happy to be wrong of course)
    - oceanparkway 2y ago
      Well, analytics and now warehousing are PostHog’s product.
hartator 2y ago
> Startups ship more per person than big companies Are they? Apple revenue per engineer is $2.4M. It seems hard to beat.
- ben_w 2y ago
  Features shipped != revenue != revenue per engineer != profit Corporations optimise for profit. Apple took 2 years to introduce the clipboard to iOS (then "iPhone OS"), and 14 years to port their own calculator to iPad.
- _xivi 2y ago
  What does revenue got to do with producing/shipping products? maybe you quoted the wrong sentence? You can have millions of dollars in revenue without producing anything, on the other hand, you can also provide a lot of services and products for free
  - seadan83 2y ago
    > What does revenue got to do with producing/shipping products? I'm quite sure a number of product people would answer "everything" Feature factories are a thing for a reason.
    - _xivi 2y ago
      > Feature factories are a thing for a reason. If anything that goes against the parent comment, how Apple has more revenue per engineer while not being a feature factory by any stretch In any case, taking both of the comments combined kinda prove my point, that higher revenue can be attributed to many things completely outside how many products/features was shipped: - Pricing strategy - You can have a monopoly with a single shitty product - You can be middle man/broker with no product to begin with - You can be running a Ponzi scheme or committing fraud So it doesn't make sense to use revenue (or revenue per team member) as a way to compare teams between different companies and furthermore possibly across completely separate markets and industry
- WXLCKNO 2y ago
jmward01 2y ago
In a nutshell this is all because of math. Scheduling is NP complete and the only good algorithm we have is divide and conquer. Team size generally matches task size and tasks should be small enough so that all options can be effectively explored in order to find a (local) optimum solution. Larger teams generally mean larger problems which mean the exploration space can get too big to effectively explore before time runs out. On big teams with big problems you eventually have to ship something so you are forced to pick the option you are currently exploring which may or may not be good. The only time this really isn't true is when the solution is standardized so that the main blocker is just 'doing' the solution and not finding it. (An assembly line is probably a good example of this).

266 points by andyjohnson0 2y ago

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).

hobs 2y ago
Also a fundamental property of small teams (which can be good) is you can only commit to so much. You absolutely know you wont ever build a lasting bridge with a six person team, but you could ford a river. This type of stuff is ok when you are in startup mode but doing this long term at big companies creates a lot of existential risk that could be mitigated by better planning. This is a tradeoff some people make knowingly (like the posthog post clearly lays out) but as usual this "2 pizza team" is cargo culted way too hard. In many cases I see the product folks with the same vision regardless of the team sizes or org fit.
- ghaff 2y ago
  Put another way there is only so much you can do with a small team—and a small company. Things change as you grow. You can do more/bigger things but efficiency almost certainly takes a hit.
tonyarkles 2y ago
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 needed $40 worth of solder and connectors and had to wait a week for PO approval as well as demonstrate that we had gotten multiple quotes... even though there was just a store down the block that sold exactly what we needed. Anyway, after a month or two of this I started catching significant flak because my team was nowhere near as productive as it used to be. Complaining about slow POs was met with "maybe you should plan better". Complaining about design reviews for one-off boards that would go from idea-to-problem solved was met with "you're engineers, you need to document your work". It was painful and I came very close to resigning. What ultimately worked, though, was figuring out a catch phrase that spoke the language of the new people: "accountability without authority". This ruffled some feathers but once I repeated "you are trying to hold me accountable for delivering a $500,000 project on time but are not giving me authority to buy $40 worth of stuff to execute on that" enough times it finally got through and the system started to change. But man did it suck for a while.
- al_borland 2y ago
  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.
  - goosejuice 2y ago
    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 autonomy. They of course won't be able to take credit in that case either :). Perhaps an overly cynical view I admit.
    - vbezhenar 2y ago
      If barriers harm more than abuse then abuse should be accepted.
      - loupol 2y ago
        Reminds me of that bits about money blogpost title : "The optimal amount of fraud is non-zero"
        Cyphase 2y ago
        https://www.bitsaboutmoney.com/archive/optimal-amount-of-fraud/ https://www.bitsaboutmoney.com/archive/optimal-amount-of-fra... https://news.ycombinator.com/item?id=32701913 https://news.ycombinator.com/item?id=32701913
        OJFord 2y ago
        Matt Levine has a recurring bit on this in Money Stuff too, adjusting the crime/fraud/risk dial back and forth as companies decide to do more or less compliance.
dheera 2y ago
> not important enough to get quick attention If you are essential to the company, it is on the company to give you the resources you ask for, or they are asses. If you have to waste time fighting for them, to the point where work can't get done, that is their problem. If you are non-essential to the company, then it is on you to start looking for a place where you will be essential, either internally or externally.
crtified 2y ago
This reminds me of a situation which I'll label "satellite office syndrome" - which is where a company has a large/dominant Head Office, and smaller regional offices which are in a permanent state of playing second-fiddle in terms of funding, attention, respect and company culture.
- kjellsbells 2y ago
  This is as true with products as with locations. For example, the people doing S3 at Amazon get everything they need, because that is a blockbuster product...and the people doing, oh I dont know, Greengrass IoT are waayyy down the totem pole even though it might be a perfectly profitable product. Large orgs tend to have a Roman Empire feel to them for most of the people, most of the time. You're stuck out on the edge of the empire, minding Hadrian's Wall, proud to be a Roman but also far, far away from any influence over or interest from the Emperor. If you are lucky they leave you alone. Occasionally a missive arrives from Rome that you have to decipher and implement no matter whether it makes sense or not. Fun times.
  - com 2y ago
    I thought that metaphor would go in a different direction, tbh. I was thinking “praetorian guards”, “imperial decline”, “decadence”, “barbariand resettling inside the limes” etc.
wildzzz 2y ago
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.
baron816 2y ago
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.
osigurdson 2y ago
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.
- seadan83 2y ago
  N choose two, not N^2. The latter double counts and also counts people communicating with themselves. For example, with 2 people, it is not 4 paths of communication, but just 1. N choose two is n*(n-1)/2, which yields the right answer In asymptotic analysis, they are the same. Except, that analysis does not make sense, asymptotic refers to the growth of the function as values approach effectively infinite
deleted 2y ago
[deleted]

hdhshdhshdjd 2y ago

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 imho once people have a “this is/isn’t my job” mentality (which again, is not a bad thing), you really need to focus on role boundaries and coordination. But the “startup” part is in the rear view.

zeroonetwothree 2y ago
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)
- hdhshdhshdjd 2y ago
  I mean this in the broad sense: like asking somebody in the sales department to lead a mission-critical database migration. That is in no way their job.
- anal_reactor 2y ago
  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
- fragmede 2y ago
  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.

shishy 2y ago

Is this similar to single threaded owner (sto) models? I'm curious how they handle things like career management and promotions but this structure overall seems great

angarg12 2y ago

> Startups ship more per person than big companies – everyone knows this. But how do you retain that advantage as you scale? Our answer is small teams > Right now we're 47 people I'm sorry, but you haven't solved scaling small teams.

TulliusCicero 2y ago
Yeah, felt like a bit of a rug pull. At that size, you've scaled only slightly; everyone in the company probably still knows each other on some level. But how do you maintain small team effectiveness in a company of hundreds, if not thousands?

ttyyzz 2y ago

I have to disagree with the "2 to 6 people" - even for small projects I feel like 4-6 people is great. This way you can ensure that everyone has a “tandem” and e.g. It's not just a frontend developer doing some mischief that someone has to clean up afterwards :D

habitue 2y ago

This is interesting, because at 47 people they're in transitional scaling. Like they've had to solve "too many teams for the CTO to manage directly" but not "too many teams to align effectively". At 15 strong self-directed teams, you can have a few teams focused on the high level directives, and a few entropy repair teams that mostly self-manage. The way to think about it is maybe like homeostasis. Self-directed product teams will implement new features, fix bugs, and generally keep the thing on track, but the efficiency drops off as the feedback mechanisms of talking to customers reaches equilibrium. To mix metaphors, a leadership team creates a kind of current flow in that system. When you're small you can go to each of those teams and ensure that current flow is happening. But at a larger size, that doesn't work. You have to engineer and carefully craft the feedback mechanisms the teams are working off of to induce that current. This is a hard problem, but it's where things like minimum attrition policies, OKRs, etc spring from: leadership trying to have a policy that induces current.

r0ze-at-hn 2y ago

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 maintenance burden. You run head first into the common problem of: "I have 1000 engineers and I can't get anything done!" In the worst case the CEO solves this by doing lay offs. Been thinking about this problem for over a decade, making effective engineering organizations that can not only grow, but change shape is difficult, but can also be very rewarding when done successfully.

marcosdumay 2y ago
I dunno. The obvious answer is that then you make another product. and another, and another. But very few companies are able to do this for some reason.
- wavemode 2y ago
  Creating products is very easy. Creating products that generate a profit is very hard. If a company could do so on demand, it would be an infinite money glitch.
osigurdson 2y ago
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.
vasco 2y ago
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.

whoknowsidont 2y ago

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.

paulryanrogers 2y ago
Or perhaps corporations grow large because they serve diverse needs. Much like users only need 10% of Microsoft Word, yet many cohorts often need a different 10% slice. Or we lack anti-trust controls, so rent seekers are soaking up markets. Maybe a combination of all three.
- whoknowsidont 2y ago
  >Maybe a combination of all three. Likely. How big each "slice" is would be good to know. I wish someone would study it in depth, if it's even possible to fairly analyze. I don't necessarily think your analogy with MS word is a fair or correct one, FWIW, only because once you build something the functionality is able to be distributed and replicated. Employees require active up keep in a way that software really doesn't.
kortilla 2y ago
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.
- rqtwteye 2y ago
  I don’t think so. Unless you get super high up, your pay increases proportionally to people under you. The next problem is that once you start cutting, you actually have to organize and manage. That’s way more difficult than saying “ I have hired x people”. I have been in countless discussions where management offered more people but whenever I told them the real problem is the process or another department not doing their job, I got silence.

malfist 2y ago

The whole section on managers rubbed me the wrong way. Team leads aren't managers and thus aren't responsible for onboarding, not communicating up the chain about perfomance, but is Responsible for performance of individuals on the team. And the phrasing about managers mostly care about happiness and team leads don't, makes me think this place might be very toxic to work for. Reeks of "brilliant jerk" acceptance and accountability without authority. It also feels rich to have a 47 person company tell you they've figured out the secret sauce of people management and team formation.

drewcoo 2y ago

> Startups ship more per person than big companies – everyone knows this. Startups can quickly change alignment to make the company work. They can throw more spaghetti at the wall to see when it's done. > But how do you retain that advantage as you scale? Once the company figures out what works, you'll want to put people and processes in place to keep it working. That means bureaucracy. That slows change. Intentionally. In big commercial kitchens no one throws spaghetti at the wall. That's waste.

arjunlol 2y ago

This was particularly bad at Meta pre-efficiency push Zuck. There was huge bloat that was counterproductive. Empire builders were incentivized by promotions based on the size of their orgs. One thing the article didn't mention is how crucial it is for a team to have focus and to ruthlessly prioritize. It's easier for bigger teams to fall into the trap of doing "busy work" and people fighting for scope on their performance reviews. This is the worst possible outcome for company and employee where you have work driven by optics vs value.

nextworddev 2y ago
Empire building has gotten rejuvenated recently at faang due to people politicking to get the fancy AI projects
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
kridsdale3 2y ago
I quit meta in large part for this reason, right before the push. My friends who stayed said the workload was hell, but I wonder if I would have experienced less manager / director incompetence. P Thiel, in 0-1 which I just started, says if you find yourself in an org where people spend more time building artifacts of showing progress, than progressing something, quit.

goosejuice 2y ago

but it has worked best for our company with these rules Sharing is good, but as others have pointed out, folks publishing such things could use a bit more intellectual humility. At this point perhaps authors just expect others read it as opinionated anecdotes. Typical thought leader dogma aside, using pizza as a metaphor for team size has always been silly to meaningless.

mathgeek 2y ago
> Typical thought leader dogma aside, using pizza as a metaphor for team size has always been silly to meaningless. An easy way to see it fall apart is to imagine a team that each eats 3-4 slices of pizza, or a team that only eats one slice each.
- verve_rat 2y ago
  Yup, in NZ a two pizza team would average out to about three people I think. Are US pizzas giant?
  - skywhopper 2y ago
    We have lots of sizes of pizza. Though I think the type they mean are the sort ordered from chain places for large groups, so usually 14-16 inches (35-40cm) diameter cut into 8-12 slices.
  - OJFord 2y ago
    I think it's meant to be an 'order some pizzas, everyone grabs a slice' sort of situation, not 'everyone is hungry and has a proper meal'.
    - mathgeek 2y ago
      If this were true, a two-pizza team would be 12-24 people (assuming a pizza gets sliced somewhere from 6-12 slices).
      - 2y ago

binary132 2y ago

Buried lede: software engineering doesn’t scale.

01HNNWZ0MV43FF 2y ago
It'll be funny if it ever does. AI replacing programmers is funny, AI replacing managers is hilarity. Also I think with open source it has scaled. I don't have to reinvent curl
- binary132 2y ago
  curl and git are amazing but they aren’t skyscrapers. Building a skyscraper, space shuttle, or integrated circuit is hard to organize even once, let alone to abstract over the process of organizing and building it so that it can be reproduced. I don’t think that problem is solved at all. And it’s not at all as simple as “just take the open source legos and slap a few of them together!”
  - defrost 2y ago
    > Building a skyscraper [...] is hard to organize even once, let alone to abstract over the process of organizing and building it so that it can be reproduced. I don’t think that problem is solved at all. Hong Kong has over 9,000 high-rise buildings, of which over 4,000 are skyscrapers standing taller than 100 m (328 ft) with 554 buildings above 150 m (492 ft). ~ https://en.wikipedia.org/wiki/List_of_tallest_buildings_in_Hong_Kong https://en.wikipedia.org/wiki/List_of_tallest_buildings_in_H... A fair number of the Hong Kong skyscrapers appear to be cookie cutter | symmetry (reflection &| rotation) patterns. Elsewhere: As of September 2023, fourteen cities in the world have more than 100 skyscrapers that are 150 m (492 ft) or taller ~ https://en.wikipedia.org/wiki/Skyscraper https://en.wikipedia.org/wiki/Skyscraper I'm going to suggest that high rise engineers have some pretty solid skyscraper templates today. The greater challenge likely comes from architects and investors wanting unique 'statement' designs.
    - seadan83 2y ago

swader999 2y ago

4-6 is ideal, over 6 people and the communication and coordination overhead starts to cost too much.

skywhopper 2y ago

God, I hate the pizza as a unit of team size. It tells me nothing.

d3m0t3p 2y ago
isn't a pizza for one ?
maccard 2y ago
It’s an abstract measure that is somewhere between 2 and 10 people. It’s deliberately not supposed to be prescriptive
- skywhopper 2y ago
  This is what I’m saying. “Between 2 and 10” is useless guidance.
  - maccard 2y ago
    I don’t think it is, at all. It’s telling you to keep teams small enough that you can manage them and have them all in one meeting
    - seadan83 2y ago
      And secondly, do not need to fill out an elaborate expense report for buying lunch. At the time of two pizzas, Anazon circa 2008, that would have been a sub $50 order.
- seadan83 2y ago
  It is one large pizza, 8 slices, that is 3 to 4 people. Yes, some people can eat more or less. If you had 10 people, you could order 2 larges but that is going to be a treat or a snack, not something that will be welcome if that is a lunch meeting.

Scubabear68 2y ago

A 47 person company with 15 teams sounds like a nightmare to me.

jWhick 2y ago

man posthog is one of the shittiest companies there is out there.

mp05 2y ago
...go on? I've been using Posthog for a few months now and it's been a nice experience.
- batshit_beaver 2y ago
  Working for them seems far less pleasant.

siliconc0w 2y ago

4-6 is reasonable but for I feel 5-8 is a bit more sustainable to add some redundancy- though that should include a technical lead who also serves as the manager (50-50) and ideally a product/program person who can maybe float between teams. It's also important that everyone is using the same standardized toolkit and shared infrastructure so each team doesn't invent their own ways of working or tooling. Some flexibility and experimentation is good but it should be clearly segmented until it's clear the innovations are worth the adoption and maintenance costs of both the 'new' and now 'legacy' system.

mp05 2y ago

>> Small teams are effectively one-pizza teams, as opposed to the two-pizza teams idea popularized by Amazon. They don't know how much pizza I can throw down, especially when the company is paying.

electrodank 2y ago

[flagged]

esafak 2y ago

Left unsaid is that smaller teams mean more hierarchy. You're not getting something for nothing.

osigurdson 2y ago

I never really understood the "pizza" metric. Why not just state the range instead?. Two pizzas can "feed" a lot of people (perhaps 16 - 20 even) if they aren't very hungry, aren't very big or aren't very young.

yen223 2y ago
Numbers are hard to remember, but pizza is easy to remember
- osigurdson 2y ago
  I tried hiring a 2 pizza team once. It was very quick, as all hiring was wrapped up in about 45 minutes. It was also very inexpensive. But, they just sat there, doing nothing. I'm done with 2 pizza teams.
seadan83 2y ago
I joked that I was a half pizza team on my own. The commute had me riding 25 miles per day on bike, I don't eat breakfast and only a light dinner -> lunch was easily 4 slices of pizza. In seriousness, pizza is not a bad measure since it means basically 3 to 4 people per pizza. Thus two pizzas is 6 to 8. 2 slices is usually assumed to be the serving size. 20 people is not even one slice per person

bogdan-lab 2y ago

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.

flappyeagle 2y ago

For a product like PostHog this might make sense. But YMMV. Their product is a collection of micro products which is pretty unusually especially for a company at their stage and size

The_Colonel 2y ago
That's an important context which kinda invalidates the value of this article. Scaling the number of independent products is almost trivially easy. What's difficult is scaling one product to a large size, since there breaking up teams doesn't achieve much on its own.

greatest69 2y ago

Small engineering teams are usually because there is no architecture team and the organization is “not yet mature enough” or their IT management sucks. Also this is marketing for consultants.

xorcist 2y ago

This could be put more succinct: Trivial problems are trivial. Of course you can keep splitting your teams when you are delivering a well defined product to customers. You could probably also have not split those teams. 50 people is trivial to manage, you could all meet in a room, should you have kept them geographically close. You may even have succeeded despite neutering those teams into triviality. You simply don't know. Try doing something even slightly more complicated: Build a bridge. Or run a hospital. Or even a pension fund. Or just a software company with a lot of products. Those nice trim teams would quickly run into the brick wall of human communication. That's the tough part of any organization. And we as a society needs to organize on large scale to get the important things done, unfortunately. Getting the easy things done is not enough.

crop_rotation 2y ago

Small teams work very very well if the team is full of competent people. Such a small team will execute much faster. The problem is that if you need to do more work at some point a small team won't be sufficient and you will end up hiring more. And as you hire more you will inevitably have quality dilution. Both communication in large team size and hiring issues make large teams much less effective.

exe34 2y ago
Communication is the productivity killer. Where before you could have three people spend 95% of their time doing and 5% coordinating, as the number of people goes up, the amount of coordination blows up geometrically. you spend most of your time discussing and very little actually gets done.
dnissley 2y ago
Oncall health is another good reason to increase team size -- having a 4 person rotation where everyone is oncall once a month is much less sustainable than an 8 person rotation where you're oncall once every two months

rco8786 2y ago

I'm a fan of small teams also - but slowing down as the company scales is unavoidable. > Startups ship more per person than big companies – everyone knows this. But how do you retain that advantage as you scale? You can't! Not really. If you could, we would see companies doing it but...we don't (barring some yet undiscovered engineering process). Everything you ship, by definition, has an ongoing maintenance cost. The more you ship, the higher your maintenance burden. Over years, this grows and grows. Output (as defined by "products shipped") per engineer must go down, because more and more engineers must be dedicated to maintenance work. Now, we've gotten really good at disguising maintenance work as product work/shipping things. But it's not reality. Even this post makes this mistake by referring to "data warehouse" and "analytics" as "products". But customers don't care about your data warehouse or your job pipeline. > Right now, for example, we're in the process of scaling support by moving our support engineers out of the customer success team and into a new customer comms team. This is not product work. This is maintenance, and is a literal example of the type of thing that larger companies have to do just to maintain their existing products and contributes to lower product output per engineer.

generic92034 2y ago
> Even this post makes this mistake by referring to "data warehouse" and "analytics" as "products". But customers don't care about your data warehouse or your job pipeline. Depending on the part of the software industry you are in, customers might care very much about data warehouse or analytics products. Particularly, those products are highly important in the ERP area.
- rco8786 2y ago
  For sure if those happen to be your actual products, but that's not the impression I got from reading this particular post. (Happy to be wrong of course)
  - oceanparkway 2y ago
    Well, analytics and now warehousing are PostHog’s product.

hartator 2y ago

> Startups ship more per person than big companies Are they? Apple revenue per engineer is $2.4M. It seems hard to beat.

ben_w 2y ago
Features shipped != revenue != revenue per engineer != profit Corporations optimise for profit. Apple took 2 years to introduce the clipboard to iOS (then "iPhone OS"), and 14 years to port their own calculator to iPad.
_xivi 2y ago
What does revenue got to do with producing/shipping products? maybe you quoted the wrong sentence? You can have millions of dollars in revenue without producing anything, on the other hand, you can also provide a lot of services and products for free
- seadan83 2y ago
  > What does revenue got to do with producing/shipping products? I'm quite sure a number of product people would answer "everything" Feature factories are a thing for a reason.
  - _xivi 2y ago
    > Feature factories are a thing for a reason. If anything that goes against the parent comment, how Apple has more revenue per engineer while not being a feature factory by any stretch In any case, taking both of the comments combined kinda prove my point, that higher revenue can be attributed to many things completely outside how many products/features was shipped: - Pricing strategy - You can have a monopoly with a single shitty product - You can be middle man/broker with no product to begin with - You can be running a Ponzi scheme or committing fraud So it doesn't make sense to use revenue (or revenue per team member) as a way to compare teams between different companies and furthermore possibly across completely separate markets and industry
WXLCKNO 2y ago

jmward01 2y ago

In a nutshell this is all because of math. Scheduling is NP complete and the only good algorithm we have is divide and conquer. Team size generally matches task size and tasks should be small enough so that all options can be effectively explored in order to find a (local) optimum solution. Larger teams generally mean larger problems which mean the exploration space can get too big to effectively explore before time runs out. On big teams with big problems you eventually have to ship something so you are forced to pick the option you are currently exploring which may or may not be good. The only time this really isn't true is when the solution is standardized so that the main blocker is just 'doing' the solution and not finding it. (An assembly line is probably a good example of this).