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 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.
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.
I work in embedded. When I told my boss I was leaving he asked what the other company was offering me - compiler licenses. Without enough each firmware build took 40-60 minutes. With enough, 10 minutes.
hey! would love to hear your experience about this. we’re building a system that should help alleviate this pain when developing embedded systems. emails / cal link are within my person site on bio!
We were using a CPU core vendor's compiler with flexlm licensing(well, Edison Design Group frontend and proprietary backend). We kept using it for ages because it regularly beat GCC due to some issues in GCC with register allocation and instruction reordering that only microchip seems to have ever fixed.
A traditional makefile like setup would only build one compilation unit per compiler invocation.
Each compiler invocation requires a license checkout over TCP. This was badly impacted by Nagling and delayed ACK. The license server was not managed by engineering rather the IT department so we were unable to get them to enable TCP_NODELAY.
Multiprocess scaling was challenging - you could give the compiler multiple compilation units, but sometimes doing so would effect the order of things in the object file, now you lose reproducible builds. These seemed to always be minor things that didn't significantly effect the executable, but rarely you'd crash the compiler and all its jobs would need restarted on the next rebuild.
For those of us batching our compiler invocations for local development builds, the last straw came when an ops team unfamiliar with the tools was put in charge of license management. They started kicking out license checkouts beyond a few seconds in the name of fairness. Build times increased further, but license checkouts per second went up so they thought they were helping.
Eventually I realized it wasn't the 1970s anymore and since I no longer smoke I was bored out of my skull just waiting for timesharing computer to compute again.
Several teams did move to GCC when it got bad enough - hand tuning loops and such when needed.
Probably shouldn't've had so much code in headers - APIs had a lot of dependencies and when I needed to change CompanyName.h, I was in for a few 90%+ rebuilds.
It was a combination of: not my problem, nobody's problem, I got mine, codebase is already like that, death by a thousand cuts, we've never better so how can you say this is bad, network latency.
> Imagine, holding a 2 hour, 10 person meeting to decide if an additional one time $1000 cloud expenditure is warranted
I don't have to imagine; I've had it happen within the last month. IT was complaining about dev's storage usage. It would have been cheaper for them to buy 10x 20tb hard drives than pay for the meeting that was called about it. Luckily, when that was pointed that out in the meeting, the dept manager agreed and ended the meeting shortly after.
If salaries were transparent and queryable this could even be a Slack or Teams plugin. But most org cultures would never dare expose salary imbalances like that.
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 autonomy. They of course won't be able to take credit in that case either :). Perhaps an overly cynical view I admit.
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.
The optimal number of (minor) crashes when training for a mountain bike race is non-zero. If you never crash, you cannot be sure you were going fast enough around that turn.
In a vacuum that's certainly the most pragmatic way to look at it. The problem is that tolerance of abuse tends to create more abuse, to the point that usually it's not a sustainable policy.
It's not tolerance of abuse. Abuse when detected will be punished. The important thing is, stopping ALL abuse preemptively causes more pain than it's worth.
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.
Nope. Abuse should never be accepted. The right solution for actual abuse of a policy like this as opposed to an error is to immediately fire the person conducting the abuse. The inability or unwillingness to make decisions like this fast is the root cause of a lot of nonsense that goes on at businesses.
If it's an error, you correct and accept errors as the cost of doing business.
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.
There is a lot of knee-jerk reaction in the line of "but what if someone abuses it! OMG!". As mentioned everywhere, the optimal amount of fraud is not zero, and the optimal test coverage is not 100%, and the minimal budget will certainly not get you there fastest, etc, etc. Some managers DO understand the problem and make it easier on their reports - but it doesn't take too many jerks to bring civilization to a grinding halt.
That was the most interesting thing about this. I still reported to the CEO directly, but some of his tasks had been delegated to finance and project management teams. So the project management folks were running their MS Project models and I had to keep them updated weekly on where everything was at, and if I spent money out-of-pocket without having it pre-approved by finance my expense claim would be denied.
When I've run into this, I've gone and bought what I need with my own money. Then I make sure my boss knows, so that it becomes a story that gets repeated up the management chain.
Even if nothing changes, it still has therapeutic value.
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.
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
That's a great story of sticking through a really tough situation and figuring out how to make it work. Honestly most of these stories end with "it sucked and then I quit". Which, fair, but not as interesting
Most stories end that way because that is the only logical thing to do. Trying to fight an organisation with a terrible culture is a sisyphean task that consumes time and energy that could be spent making stuff.
Some organisations (like the one I'm working for) seem to be run like a dystopian daycare. Stay in your box, be "respectful", don't complain about your terrible manager, don't complain about the hoops you have to jump through to get even the most simple or meagre of resources. The internal communications are heavily monitored and that has a chilling effect on cross-team collaboration.
They have even weaponised their "culture" in a way that coddles the offending teams in the structure and still direct blame for missing deadlines at the victims rather than the perps.
There is no fighting this. My small team are all aggressively looking for new jobs which is a shame because they are a tight crew with great skills who have now been beaten down as far as they will go. A great loss to the organisation when we walk too, all that institutional knowledge gone.
Different strokes. For some people, the desire to “build stuff” extends to building (improving? refactoring?) the organisation. For some people, tech problems that are just tech problems is, creativity wise, like eating meatloaf through a straw. Myself included.
Yeah, that definitely played a part in it. I was employee #2 and had built an absolutely amazing culture in the team that I ran. I stuck it out in large part because I loved how well we worked together. The project was cool, too, which helped, but not wanting to abandon the team of fantastic young engineers I'd pulled together was the thing that kept me fighting.
I semi-jokingly-but-not explained to them what a Shit Umbrella was and that while all of this was going down I regretted not being as available to them as I had been, but that I was doing my best to give them an environment where they could keep doing the amazing work they'd been doing without getting dragged too much into the bog with me.
Heh, it was a small startup. And then there was a $x0 million seed round and suddenly we became a much larger startup. When we hired a bunch of business/management-type people who had all worked together at another organization they imported their broken culture. (We were able to hire all of them because their previous organization had had a significant layoff... and for the record I had nothing to do with their hiring, they all just kinda showed up one day)
Same. I quit Google to go work at a 4 person company. I love that we’re just able to get stuff done. Hard to get GPUs? Walk down to Central Computers in SOMA and buy L40S cards and build a workstation for everyone to share.
I’m not very financially motivated. I’m already making more than 90+% of the US. I just can not fathom the level of greed I saw hiding behind people’s eyes at Google as they try to build empires. I’m in Silicon Valley to learn about and work with computers. I get to work a chill number of hours while still learning every day. If you could get a lot of employees like that you’d have a huge market advantage.
I'd rather die than become that. And there were plenty of Googlers there just chilling making good money. It's the mid level managers that were making around 500k eyeing up the 1MM comp packages that were the problem.
5 or 6 most days. I’m of course happy to do more in sprints when duty calls. Working at 100% is fun - as an exercise. Like training with weights on. Maybe your site gets DDOS’d. Maybe your database has a critical issue. As long as you’ve done some prep these are recoverable issues. And solving big problems tells you and your boss that you’re important.
But honestly most of the time I’m able to take my best thinking hours of the day, put those into the job, and get 90% of the output with much less than 90% of the time. The worst thing you can to is try to fill the time and create a bunch of tech debt. Artificial time scarcity keeps things lean.
> I just can not fathom the level of greed I saw hiding behind people’s eyes at Google as they try to build empires.
That’s very well written. Poetic even.
> I’m in Silicon Valley to learn about and work with computers.
The industry used to be more like that. Never entirely, of course - Microsoft made a bunch of people millionaires in the 80s and 90s, turned some heads. A few others did too.
Even in the early 2000s almost none of the MBA types were going to the Bay Area after graduating.
But things changed. It basically had to. There were too many companies making too much money - and making their employees too wealthy - for people to ignore it. Zero interest rates added fuel to the fire and everyone who could jumped on it. Late stage capitalism, everyone gotta get theirs. And here we are.
The most frustrating part of working in the tech industry for me is that when it was smaller, it was a given that you would work with people who loved the tech. Now the industry is filled with people who are "in tech" but have no real interest in the technology itself, and in many cases aren't even slightly technical. They're just doing it for the money and because everyone told them it was a good field to go into.
There's so many of these people that it's really hard to avoid working with some of them. I consider myself extremely lucky because I started a business and when these people show up, I can choose not to promote them, or straight up fire them, or find some other way to show them the door. But the broader ecosystem we're in is something I have no control over, and it has clearly changed, so that it's not just filled with people who don't know or care about the tech, it's run by them (and in the long term it shows as the tech degrades).
You might be missing the dot com boom in your analysis. MBA types flocked to the tech sector looking for those IPOs, a trend that I suspect has only grown stronger since.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
Too many people (in finance, mostly - which drives the rest: entrepreneurs, "big" managers, etc.) in the industry (like to) think that maintenance is bad, because it's not new or growth-capable (which is where they expect to get more, and more, and more).
But maintenance/routine is actually most of the work for everyone, everywhere on this planet. Which is good work.
You can/may outsource, or automate (it's the same actually: getting the same output for a lower cost), it. With the consequences it comes with.
You can/may prefer to be in the 1% of innovation too. But once you innovate (on) something, you've got to maintain it. Someone has to.
The good places where to work are those that admit, and implement (in their structure, in how the manage people and their expectations), that maintenance is most of the work, and that innovation is the small part of it.
It's like in art: most/99% of the time, you practice, you learn. 1% of the time, you get to do/find something great out of it.
Which leads me to the dullness of generative AI: you can't have the 1% if you don't go through the 99% - and you may not understand this if you never tried once to get through those 99%.
> 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.
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)
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.
Most managers love to repeat "saying it's not my job is terrible attitude" while assigning unreasonable targets and stuffing items in the Sprint to the extent that even sneezing hard will make you overrun your deadline. So I am expected to deal with non prioritized work with a smile so that I have to steal from time set aside for my family in order to make the sprint target? How is that not bad mentality?
Yes, you are expected to deliver the message to García without question or complaint. Managers love initiative and self-reliance, but only in service to faithfully obeying their commands.
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.
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
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
'i need more people' or 'i people with this specific skill' is also a really good blanket excuse for dysfunction. and if you dont get the slots you can just say 'i told you', and if you do get the slots and dont feel like actually executing, its pretty trivial to find all the candidates wanting. or blame the hiring market. or the low salaries. its a hugely effective dodge, and you can even convince yourself that you're doing all you can to address the problems in your organization - you just cant because of factors completely outside your control.
It’s well known that middle managers love to grow headcount. That doesn’t matter.
If teams aren’t resulting in profit, they’re gonna get pressured to make cuts or will have RIFs imposed on them. I’ve seen this happen at every company, even big seemingly inept monsters like Oracle and IBM.
Those political middle and upper managers who are good at growing headcount are also good at shifting blame. They explain their lack of profit by either not enough headcount or else some other part of the company is letting the down (and they should take over that function so they can succeed next time) etc
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.
There are some roles like that in tech. For example, "charitable" positions like full-time OSS devs.
Another one that is questionable are tech evangelists or dev rel. Sometimes those positions can be connected to revenue, but usually it's "mindshare" accounting.
OSS dev might be a bad example. OSS is often an internal product that is opened up to gain free OSS labor. Most often, the position would exist within the company if it were OSS or not. In other words, it is something the company is working on regardless of OSS or private codebase
You are totally correct basis my observations. However, companies can not be smaller as past a certain scale a company resembles a communist economy. Having read the book "Red Plenty", I saw so many similarities with the big techs I have worked at. Internal teams have a top given monopoly and have no incentive to improve their products unless there is some external competition. Most companies are now led by people who have much less skin in the game (up to the CEO level in most) and every small org resembles a factory in the soviet union. The incentives of everyone working at the company is to keep growing bigger.
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.
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.
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.
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.
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!”
> 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).
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.
You make good points. I think this illustrates well that software engineering is much more akin to writing than it is to carpentry/construction. Thus, a team of software developers is more akin to a team of story writers than a team of carpenters. A software company is more akin to a newspaper (writers/reporter/chief editor) vs a construction firm (business giving direction to an architect and in turn a foreman + dozens of laborers)
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.
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.
Well alright everyone grabs a couple of slices, I'd say typical is 8 slices per pizza right, so that works out to 8 people, which yes is what it means doesn't it? (Not literally 8 but in that 6-10ish region?)
My point was if you interpret it to mean a full meal for hungry people a two pizza team is like 2 maybe 4 people, because 'a pizza' is an order, unless these are enormous fast food 'party size' type pizzas.
2 slices is considered to be a meal. Calorie wise, it likely is. Typical large pizza has 8 slices. The vagueness is intentional. From the Amazon concept, it is intended to replace a meal and not be a random snack. (Former amazon employee here)
Sure I'm not really getting into whether or not it's supposed to serve as your lunch and whether it's a healthy limit even if you'd like more^, etc. - I just mean it's meant with the assumption that people are having that much, not that it's your orders at a team outing to an Italian restaurant or something. (In which we agree.)
^personally I work from home and rarely eat lunch, so I have no skin in this!
Regional/cultural differences, appetite and body size, pizza styles, etc.
For small teams that makes for a meaningful difference between the min and max. For large teams not so much.
My wife and I have no issues finishing a 16in tavern style pizza. So that's a 4 person team. We're not even large people or big eaters. We just like pizza.
I hear you. I love that you can share a favorite food like that with your partner :)
When I worked for amzn.. I was eating approx 3500 calories a day - long bike commute. Pizza was always disappointing as rarely enough (and even then, eating my fill would be too much. I had to go out and still buy another lunch anyways* - and almost always not enough veg pizzas!). We perhaps could get into the variety of factors, yeah, eg: nutrition density to as a function of toppings.
Though.. if you look at serving size and how many people a large is meant to feed, it is pretty simply just 3 to 4.
* worse yet, because lunch was delivered, there was an expectation to work an extra hour that day (ie: working lunch meeting, and certainly do not go home early). Foing out to get enough real food and suddenly I was the bad guy for being the one team member not in office. Actually buying lunch was easier, I would just buy two at once.. Thinking back to that time, holy shit the work expectations were something else..
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
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.
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).
> 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.
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.
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.
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
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.
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
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
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?
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.
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.
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
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.
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.
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).