> Systems that don’t scale, or that are reliant on the grunt work of humans, are not part of the training of engineers either. For so many engineers, an unscalable, human-dependant system is a bug, not a feature.
There's a specific discipline within Engineering, of people who put together technology with employee training manuals, company policies, and sometimes even incentive structures which bring into existence entire markets, to make sure a process is carried out. These people are called Systems Engineers.
A typical Systems Engineering problem: design a satellite launch mission. Piece out the work, the calculations, the part sourcing, the safety checks, etc., so no part (human or computer) will malfunction or "jam" without a redundant backup being ready to take over. Make sure all work and outputs have been checked. Make sure all people, parts, and processes for doing the checking have been checked, and are regularly maintained. And make sure all relevant processes are adaptable to changing demands in the future, so this mission design can be reused to build and launch another satellite, later, even if we don't have the same companies to source parts from, or the same employees, or even the same satellite. Make sure all this making sure continues to happen after you're gone, without anyone in particular needing to keep the whole thing in their head--because that's way above tolerance for an average human "part" in your System.
A Systems Engineer's work, especially at the prototyping phase, involves just as much talking to and convincing customers and partners, providing training and walking through use-cases, as it does writing code or doing calculations or building models.
You might have guessed where I was going with this. Start-ups are indeed Systems Engineering problems, and really, they need Systems Engineers to build them. I would say it's a shame that we consider someone an Engineer at all without training in Systems Engineering; it really is the holistic body of training tying all the other Engineering disciplines together. A Civic Engineer could model a bridge, but a Civic Engneer with Systems Engineering training can model the structure of the maintenance contracts required to upkeep the bridge, and find the most cost-effective incentive to encourage people to avoid trying to take their oversized cargo boats through the pass. In a way, Systems Enigneering has a lot in common with Game Design--just with the proviso that the "game" is played by real people as an aspect of their real, every-day lives, instead of writhin a voluntary Magic Circle of play.
I should note, though, that as a Systems Engineering problem, "starting a start-up" has a unique property--rather than being built and then launched, start-ups are launched, and then built. A startup is basically a partially-designed seed System, which has just enough utility to "live" (it's Minimally Viable!), and which will then require more Systems Engineering to be done "in-flight" (customer discovery/pivoting) to keep them viable. This necessitates a Systems Engineer actually be a component of the seed System, as architected, at least until the System reaches a state of maturity (which is precisely defined as the point at which a Systems Engineer is no longer needed for the System to avoid "running down."
If you'll indulge me in a metaphor, a start-up is like a modern fighter plane. It used to be that, having lost power, a plane could simply continue to glide toward its current (ballistic) trajectory, because it had static stability. However, it turned out that statically-stable designs had weaknesses (warping under sufficient torsional forces, for example) and to increase manouverability past a certain point, static stability would have to be sacrificed. In a modern jet fighter, then, we have a plane constantly tending toward shaking itself apart--and a set of electronics giving it continuous micro-adjustments so it won't. In other words, we have a System that can only function as long as there is an intelligent agent adjusting and tuning it from within.
--where the parallel breaks down, of course, is that a fighter plane flown for long enough doesn't continue to grow until it becomes a Boeing. But then, if they had aviation control electronics as intelligent as a Systems Engineer, I don't see how getting a fighter plane to pick up parts, join them to itself, and expand out until it could fly passengers five days a weeks would be an intrinsically harder problem than turning an idea in your head into AirBnB.
One thing you should be able to notice from my description above: there's no reason the Systems Engineer running a start-up, has to be the one who designed the start-up's seed System in the first place. I would say that the whole point of a start-up "incubator" like YCombinator is to do most of the Systems Engineering work in constructing viable seeds--including picking good teams of Systems Engineers to run them. That the people executing on their Systems are frequently the ones to suggest the initial idea for the seed System they end up working on is more an artefact of human-nature+ than anything to do with YC's business model as such. I would flip the role terminology around: YC engineers the seeds; then the founders--part of the constructed seed System--incubate it, until it no longer needs continuous System Engineering for its ensured viability. (At which point the founders either give up on being Systems Engineers, or leave to start something else.
Another fun analogy: a start-up requires the care of its founders in the same way a fortis requires the environment of the womb. This would make YC an IVF clinic--though with some aspects of a pre-natal care facility as well. :)
+ Less cynically, YC can be said to just be making the capitalist assumption that knowledge of what the economy wants is distributed among the people on the ground in each domain. That's assuming the founders have knowledge of their domain...
There's a specific discipline within Engineering, of people who put together technology with employee training manuals, company policies, and sometimes even incentive structures which bring into existence entire markets, to make sure a process is carried out. These people are called Systems Engineers.
A typical Systems Engineering problem: design a satellite launch mission. Piece out the work, the calculations, the part sourcing, the safety checks, etc., so no part (human or computer) will malfunction or "jam" without a redundant backup being ready to take over. Make sure all work and outputs have been checked. Make sure all people, parts, and processes for doing the checking have been checked, and are regularly maintained. And make sure all relevant processes are adaptable to changing demands in the future, so this mission design can be reused to build and launch another satellite, later, even if we don't have the same companies to source parts from, or the same employees, or even the same satellite. Make sure all this making sure continues to happen after you're gone, without anyone in particular needing to keep the whole thing in their head--because that's way above tolerance for an average human "part" in your System.
A Systems Engineer's work, especially at the prototyping phase, involves just as much talking to and convincing customers and partners, providing training and walking through use-cases, as it does writing code or doing calculations or building models.
You might have guessed where I was going with this. Start-ups are indeed Systems Engineering problems, and really, they need Systems Engineers to build them. I would say it's a shame that we consider someone an Engineer at all without training in Systems Engineering; it really is the holistic body of training tying all the other Engineering disciplines together. A Civic Engineer could model a bridge, but a Civic Engneer with Systems Engineering training can model the structure of the maintenance contracts required to upkeep the bridge, and find the most cost-effective incentive to encourage people to avoid trying to take their oversized cargo boats through the pass. In a way, Systems Enigneering has a lot in common with Game Design--just with the proviso that the "game" is played by real people as an aspect of their real, every-day lives, instead of writhin a voluntary Magic Circle of play.
I should note, though, that as a Systems Engineering problem, "starting a start-up" has a unique property--rather than being built and then launched, start-ups are launched, and then built. A startup is basically a partially-designed seed System, which has just enough utility to "live" (it's Minimally Viable!), and which will then require more Systems Engineering to be done "in-flight" (customer discovery/pivoting) to keep them viable. This necessitates a Systems Engineer actually be a component of the seed System, as architected, at least until the System reaches a state of maturity (which is precisely defined as the point at which a Systems Engineer is no longer needed for the System to avoid "running down."
If you'll indulge me in a metaphor, a start-up is like a modern fighter plane. It used to be that, having lost power, a plane could simply continue to glide toward its current (ballistic) trajectory, because it had static stability. However, it turned out that statically-stable designs had weaknesses (warping under sufficient torsional forces, for example) and to increase manouverability past a certain point, static stability would have to be sacrificed. In a modern jet fighter, then, we have a plane constantly tending toward shaking itself apart--and a set of electronics giving it continuous micro-adjustments so it won't. In other words, we have a System that can only function as long as there is an intelligent agent adjusting and tuning it from within.
--where the parallel breaks down, of course, is that a fighter plane flown for long enough doesn't continue to grow until it becomes a Boeing. But then, if they had aviation control electronics as intelligent as a Systems Engineer, I don't see how getting a fighter plane to pick up parts, join them to itself, and expand out until it could fly passengers five days a weeks would be an intrinsically harder problem than turning an idea in your head into AirBnB.
One thing you should be able to notice from my description above: there's no reason the Systems Engineer running a start-up, has to be the one who designed the start-up's seed System in the first place. I would say that the whole point of a start-up "incubator" like YCombinator is to do most of the Systems Engineering work in constructing viable seeds--including picking good teams of Systems Engineers to run them. That the people executing on their Systems are frequently the ones to suggest the initial idea for the seed System they end up working on is more an artefact of human-nature+ than anything to do with YC's business model as such. I would flip the role terminology around: YC engineers the seeds; then the founders--part of the constructed seed System--incubate it, until it no longer needs continuous System Engineering for its ensured viability. (At which point the founders either give up on being Systems Engineers, or leave to start something else.
Another fun analogy: a start-up requires the care of its founders in the same way a fortis requires the environment of the womb. This would make YC an IVF clinic--though with some aspects of a pre-natal care facility as well. :)
+ Less cynically, YC can be said to just be making the capitalist assumption that knowledge of what the economy wants is distributed among the people on the ground in each domain. That's assuming the founders have knowledge of their domain...