In this post, I argued that business founder/CEOs need to make many decisions well in order to be successful. You cannot just have a cool idea or a nifty strategy.
Look at how many successful CEOs in recent years have had reasonably good coding skills: Jobs (not in Wozniak’s league, but who was?), Gates, Musk, Page/Brin, Bezos, Zuckerberg, Collison. Why does computer programming skill matter in a CEO?
Perhaps coding skill is just a proxy for “being smart.” But in that case, people with high SAT scores and who happen to not be software engineers should be able to produce spectacular businesses. That does not seem to happen as much.
Although running a business may look easy from the outside, it takes a lot of skill. Most people, whether or not they know how to code, lack the skills to run a business, especially a complex one.
I think that so many complex businesses today depend on software that to be a business leader you need a sense of the software development process. You need to know what sorts of projects are easy, what sorts of projects are hard, what sorts of issues to anticipate concerning maintenance and change management, etc. And I suspect that most people who have never written code have a poor sense of how software is built and maintained.
A lot of businesses cannot execute good ideas because they are hemmed in by their software systems. You think you are trying to make a simple change, and you are creating a cascade of problems.
When I was at Freddie Mac in the late 1980s, it was amazing to me how unadaptable the systems were. The systems were as rickety as the electrical system in a building first constructed decades ago, with the original wiring still in place, patched by additions and modifications tacked on every few years. The wiring would be so tangled and delicate that any change has to be carefully studied and slowly implemented lest the whole building will fry in an electrical fire.
I formed the opinion, which I took with me to my own business, that putting off rewriting a system and letting it accumulate patches is a bad idea. I was willing to say yes to total rewrites and inclined to say no to patching.
Jeff Bezos’ “two-pizza” rule—that software teams should be no larger than a group that require two pizzas to feed—amazes me. Getting that to work requires way more discipline than we had at Freddie Mac, where people were constantly implementing workarounds to the existing systems. The cross-departmental impacts wound up being very hard to manage, and any important project required a large team.
To keep project teams small and not have them mess up one another, the interdependencies have to be very clean and very explicit. That takes a rigorous approach to coding and, especially, to documentation. But I imagine that if you can pull it off, it facilitates great organizational flexibility.
So I think that to be a great business leader today, chances are you need to have a good feel for the software development process. That is not sufficient, of course. There are many other decisions that you have to make, including key personnel decisions, starting and stopping projects, shaping corporate culture, and all of the rest.
But I repeat that when it comes to complex modern businesses, luck plays only a small role in success. Business is not then one day he was shootin’ at some food, and up from the ground come a bubblin’ crude.
I think you pretty much nail it, although I don't think that having your business even be highly software dependent is critical. I think programming teaches you to think hard about exactly what is happening at each step, exactly what inputs are needed, exactly what outputs are produced, etc. That's as opposed to almost every field involving humans where hand waving and vagueness can often be interpreted by others who know better and can make it work. Most people just can't think seriously about processes and interdependencies, even when their job depends on it. (I see this all the time, working in supply chain ERP system implementation. "Technical" people often get just as handwavy as business, but often because the business side lets them get away with it.)
My guess is that is why folks from the hard sciences tend to do well as business managers too. You can't mumble your way into building a functional bridge, or rely on "then a miracle happens" for step six in mixing up chemicals. Anything where "do it right, in the right order, or it doesn't work" is a good training.
At a high level of abstraction and 'architecture' coding really is the same skill as coordinating human efforts in organizations.
One has to manage complexity at scale in accomplishing a giant, multifaceted mission by divide-and-conquer and division-of-'labor' approaches, arranging hierarchies of compartmentalized, special-purpose functions, outlining paths of communication, and authority, allocating scarce resources intelligently, and constant testing, detection and elimination of 'bugs', with iterative-decision-making and refinement of processes and procedures ('instructions') for quality, reliability, and efficiency.
The basic outline of a modern efficient world-class organization is kind of like a general purpose CPU (they all tend to share similar basic design) with the founders / CEO programming and improving the human-coordination software to make it produce the intended outputs.
With hardware and software, the individual components and routines are both amazing because specialized to do one particular task extremely well, and dumb, because they can't do other tasks efficiently and often only get to work with a tiny piece of the puzzle. The art of managing and arranging the big picture, and to make sure that functions are able to run in parallel on different cores (or brains), and still deliver intermediate outputs just in time for other subsequent functions takes extremely high levels of talent.