That’s a question I haven’t seen discussed in blogland, even though it’s one many early stage companies grapple with.
I received an anonymous comment on my post Visit to Microsoft in Dublin:
are you one of those non-technical people who think they can manage a software company?
the idea of a non-programmer bossing around programmers is retarded and very common. you’re already spewing bullshit at the tender age of 18!
talk to me about adding closures to C# (do you know what a closure is?) or dynamic vs. strongly typed languages (do you know what that means?) for implementing web applications or something. don’t say "web 2.0 will be all about collaboration in the enterprise" or other meaningless garbage.
Putting aside his assertion that age 18 is tender — ah, what a lovely thought — he does bring up a legitimate point about non-programmers.
One ideal set-up in a start-up software company is to have a few technical guys and one straight shooting business guy. Some guys like Paul Graham like to say every start-up should be employed by "hackers" or "geeks" but I don’t share this view because I don’t think great functional software products is what makes a software company successful. Moreover, hackers tend to share a certain worldview (such as perfectionism, a deadly path for any start-up) which can shut out other perspectives.
The reason why I think there’s a legitimate role for the non-technical person at a software company is that evaluating the quality of the raw code (sort of what Anonymous Commenter is asking me to do) is not, I think, what dooms most software development projects. Communication and management seem royally important, since so much rides on managing and meeting expectations.
The non-engineer must have meaningful expertise and experience in his/her "shallow" area of technology, but doesn’t have to be able to write code. What does this mean? He could have a reasonably detailed discussion about the application’s architecture and programming methodology. He neither would accept such programmer bullshit as "It will be done when it’s done" nor pull off such business-suit bullshit such as "Hey, add a feature that does X" without detailed specs. He could have conversations about collaboration among programmers, about source control, about deadlines and specs, about cost estimates. And when necessary, he could roll up my sleeves and get dirty (like I tried to do a few months ago when I built a PHP/mySQL simple web app that processed movies).
Likewise, for a technical person to have meaningful expertise in his shallow area, it would mean understanding that it’s not about the software, it’s about the customer problem. It’s not about perfection, it’s about "good enough." It would mean realizing that businesses make promises based on deadlines. Most important, it would mean the technical person could communicate effectively to his co-founders and to other programmers. Since so much of software development seems to be about managing and meeting expectations, the most motivated and effective programmers are often those who communicate the best.
So to answer the question. From my vantage point, non-engineers can indeed run software companies, assuming three things:
1. They have co-founders or colleagues who can assess the raw quality of the code.
2. They have meaningful expertise and experience in their "shallow" area — software development, managing engineers, specing projects, such that they can effectively bring to bear strong communication and management skills in this kind of environment.
3. The company is not selling its wares to programmers or any other highly technical market, in which case an all-coder lineup could work since coders are the customers.
What do you think?