"You haven't worked in a big project, have you?"
"Big project" is, I suppose, a relative term, in your case no doubt based on how many people were hired to do something... The systems I referred to control about a million dollars worth of equipment per installation. Which is about 1/4 to 1/6 of the equipment at each plant. They sold for an aggregate of a few million USD and were sold at 400% profit, or five times what they cost to build/install to the private manufacturing sector. It was a nice little niche...
I don't define the size of a project based on how many people are hired to work on it... I define it based on what must be done to accomplish the desired goals. I've done more with less throughout my entire career -often because we had less to do it with. I am not a fan of bloat, waste, or paperclip counters or an endless series of meetings and reports and "managers" that in no way move a project forward. The smaller the core group the better, as far less time is required to communicate vs. actually accomplish. The only organism with more than four feet, multiple heads, and no functioning intelligence is a committee.
People who make blanket statements like "None of the projects I've worked could have been done only by a person.", make me wonder. Unless you're basing that on the timeline alone, nearly any project can be completed by one individual of sufficient competence. It just generally takes longer, and you have to WORK. When I designed the prototype that I mentioned, and it was a complex system flexible and elegant enough to be redefined by a "monkey" -or at least a person with no programming ability, to fit other similar plants with widely varying equipment layouts within the particular manufacturing industry, I worked 60-80 hour weeks for 18 months or so. But, it was a labor of love, really and I was working to gain half a corporation before my thirtieth birthday. I didn't work completely alone, except programming, I had a fellow retired from AT&T who did part ordering, and took over prototyping hardware once I'd built initial breadboarded designs.
Frankly, I think most IT teams are far too top heavy with "managers" who can't or don't, are buried in too many gaant charts, flow charts, and diagrams, and spend far too much time writing reports detailing why they're not making progress by blaming other teams and dependencies.
My process is simply to take a problem, break it down into manageable chunks and then further subdivide until each can be dealt with, and then do it. My docs are written as comments as I write code -with a time/dated progress log at the head of each file being edited, and if you can't figure out how the code works and follow it's evolution between the log and the comments provided you are not yet qualified to touch my code -go back and read it until a gestalt forms. Period. End of sentence. I am verbose and I lean toward simplicity.
By the way, the derisive or dismissive nature of your comment wasn't lost on me. I filed it in the category I reserve for other people given to describing how large something they are in some way attached to, or may be attached to them, is... do you by any chance drive a flashy red sports car?