30% Management skills
10% Mental strength
5% more luck
5% Technical skills
Now I know that all you geeks will be raising your eyebrows after seeing the last item on the list. Frankly, software industry is not the place for you, go and do research, don't waste your Grey matter.
Believe it or not, you will surely need a lot of luck even to survive, let alone be successful. You will understand this once you get to know about how projects come into existence.
First of all, some top-level management guys have to find out something that people need (or atleast think that there is something that people need). After that there will be some 20 or so companies fighting it out to get hold of that project (or part of that project). Usually this is decided by doing a small prototype of the actual thing in about 1 month. This prototype would be done by a very small team, only about 1/10th of original.
Now you can imagine that most of them would show up after one month with almost the same thing. Now the guys at client side have to determine which one of them is best. Since most of them turn out to be almost the same, the selection can be as random as throwing a dice. It will depend even on they had for breakfast that morning.
So finally your company gets the project and starts working on it. The team gets expanded by a factor of 10, managers fly-in from everywhere and take charge, schedules are prepared and.. kick-off...
Now that you have finally started working on the project you have to ensure that you are in good terms with your colleagues (not that difficult), managers (Moderately difficult), and HRs (very difficult).
If you were in the team which was doing the prototype, then you are going to get lots of requests to do other people's work. If you say "Yes to all", then you will be one of those who gets stuck at office and burn midnight oil. If you say "No to all", then you are at the risk of pissing off some of your colleagues. Unfortunately, the aforementioned two responses are the most popular for a programmer. I wonder when we'll learn to say "Yes or No appropriately" instead of a "Yes to all" or "No to all".
Now assuming that you were not part of the team initially. Then you have to get others to talk so that you could learn about the project and start being useful to the course. If you don't, you better be good at pretending (and convincing) that you are really important for the project, which again is MBAish skills.
How would you respond when customer wants a code clean-up and your auto-indenting tool doesn't work as expected, or the hardware doesn't work according to the spec and it takes two days to find out. These are exactly the kind of nuisances that you face while being a software engineer. Lets face it, nobody is going to do all the dirty work for you, sometimes you have to dig deep and do all that dirty stuff (Fixing makefiles, copy-pasting poorly written code...) to survive in the industry.
After all the dirty stuff, some technical stuff has to be done to make the customer happy. And it is the 10% you are actually going to enjoy.
I'm not claiming that the situation is exactly the same everywhere. But with my experience and what I hear from friends, it's pretty much the same.