The importance of quiet, long extended coding sessions, the irrelevance of meetings longer than 20 mins, the painfulness of some aspects of coding (like yak shaving), the preference towards email (I can read 500 wpm and listen at 60, plus I can read when I need to, rather then just when you are talking) are all way more important than understanding CSS vs HTML. You should be trusting those types of things to the technical guy as he should be trusting you for content marketing strategy.
Just 3 things:<p>1) Things get broken all the time:
so instead of playing the blame game & doing name calling.Expect that things will break & assume there will be bugs. Focus should be fixing the problem ASAP & _then_ doing an analysis on what went wrong. so corrective measures can be taken so the same problem does not reoccur again.<p>2) 9 Women Can’t Make a Baby in a Month:
If you had more capital, could you finish things faster? NO, look what happened to Color(about 200employees, IIRC) & compare that to instagram(10-12 people) . In software eng, More resource does not necessarily mean better product.<p>3) Don't bother about coding, but test the shit of product to provide honest constructive feedback. Plus, be the public face of the company. technical people prefer doing programming rather interacting with random bunch of strangers.<p>These are the main three ones, I could think of top of my head. Hope it helps :)
1) Just because your technical co-founder got there requirements, is smart, and can do this stuff on his/her own, does not mean that you can EVER be hands off. It is demoralizing AND does not build a close relationship between you two.<p>2) Let the tech co-found show stuff to you, even if its code. Try to understand it or understand the significance. Tiny show-off sessions can go LONG ways towards morale. Also you can catch problems early this way.<p>3) Offer help even if being rejected. Again, helps with morale if the tech co-founder knows hes not in the boat alone, even if he he/she is the only one who can row.
In addition to overall technical concepts, its nice if the business person understand the product development and software release process, and have some development exposure. Code breaks, build fails, software fails - all these things happen in the development and could be fixed. Lots of business people just do not count these factors and that's many fail, not because of the software, but because partners could not work together.
It's so important for non-technical co-founders to trust their technical co-founders, and to make a huge effort to communicate as clearly and unambiguously as possible.