It took me a while after arriving at Scrollmotion to realize that our software was like a really great magic show. It looked amazing, was smooth and seductive and made people go "ooooh" at just the right moments--but as an actual product, as opposed to a pre-sale demo, there was too much smoke.

I am an engineer, and built enterprise apps at Apple, so I could look at our source code and see where we went wrong. When I did, I realized we needed to go back to square one, or maybe square two: We spent the next year re-coding our product from top to bottom. It was a slog, but meant our product was finally ready for prime time.

So how techie do you need to be to run a tech company? Plenty of successful tech shops have non-technical founders, including Brian Cheskey (AirBnB), Michael Bloomberg (Bloomberg LLC), Chad Hurley (YouTube), Larry Ellison (Oracle), Steve Jobs, and many others. But if you don't have a technical background you can still help your company avoid pitfalls like the one Scrollmotion fell into.

Here are six ways a non-technical leader can keep a close eye on her company's tech stack. (In another column, I'll explain how to evaluate--and better work with--your engineers and other technical staffers.)  

Stay Out of (Technical) Debt

iOS is an evolving creature; from one generation to the next, features and capabilities build on one another. To take one geeky iPhone example, your company had to have adopted Auto Layout in 2012 in order to implement 2015's split screen feature, and you needed to have adopted both in order to implement this year's new Drag and Drop functionality. Each requires significant engineering investment on your company's part.

Every time a new release comes along, you need to ask your engineers: "What are we doing to implement the new iOS features and when are they going to be done?" If you fall behind, it's really hard to catch up. And that's true on any platform.

Play with your product

This sounds obvious, but trust me, it is violated all the time. Whatever you're making, be sure to use it constantly. If it's software, install new builds religiously on your device--ideally, nightly--and explore every aspect of each iteration. Keep a running list of bugs, observations, suggestions, and establish a structured, regular review with your team.

If you see something, say something

Software and hardware are both expressive; when there are flaws, they reveal themselves. As you use your product, be alert to pain points, awkward interfaces, counterintuitive moments. Pick up the rock, look at the worms underneath it.

If you are questioning something you see, speak up. Get answers. There's probably a technical or design glitch in there somewhere. Don't hope the problem goes away--solve it.

Think about your user

On any platform, the key to creating a great user interface, is getting grounded in what everyone else is doing. In usability, you don't invent patterns of behavior--you respect them. Go download the top 25 apps in your industry (or whatever you need to understand the rules your peers are playing by) and familiarize yourself with them. Then go use your own. Watch outsiders do the same. Make sure they aren't confused, lost, frustrated.

Ordinary people should be able to navigate your app and/or use your hardware. Challenge yourself--and your team--to simplify your thinking.

Your security mantra: CYA

For non-technical types, the first step to security is to routinely search Twitter and Google and simply keep abreast of the latest news--the latest flaws, exploits, patterns, methods of intrusion. Some of it will be in technical jargon but it's important to know what's going on, if only so you can make sure your security team knows--and is acting on it. Apple's security whitepaper is absolutely required reading for anyone working on their platform.

If you have any doubts, spend the money on a security audit.

Expand your consciousness

Build into each week a scheduled time to develop your technical vocabulary and your understanding of key technical concepts, such as UI, UX, API, SSL, HTTPS etc. Being technically naive in the early days doesn't absolve you of the responsibility to grow. It sets an example for the entire company--and radically improves communication.