As a founder of a software company, I often get asked about my ability to code. The answer is simple: I can’t code at all.

At first, I thought what many young and eager entrepreneurs think-- that I must learn how to code.  So I downloaded a bunch of files to help me learn Ruby on Rails. After my first lesson, I was able to code my name forwards and backwards and perform simple math equations.  That’s about as far as I got.

But I’ve still been able to build a software company that reduces recruiting inefficiencies for more than 250 companies. And I learned several lessons that are key to running a technology company without a technical background.

1. Understand the real motivations behind why people work with you.  If you can’t understand what motivates your employees and what it takes to keep them happy with their career, your organization is doomed. In the interview process, I try to ask questions that will uncover what really motivates a developer.  I can’t administer a coding exam, but I can certainly try and make our work environment conducive to productivity and success.

2. Under-promise and over-deliver. As a first-time non-technical founder, I built credibility with my development team by promising that we would hit certain milestones such as getting accepted to an accelerator program, landing great co-working space, and raising capital.  I always articulated the things that we could achieve together as a team, and didn’t rest until I delivered what I had promised.

3. Communicate “wins” on the business side driven by innovations on the tech side.  It’s easy to speak about business with your sales and marketing teams. But the development team needs to be engaged in the business wins, too. When developers see their work transformed into real revenue and happy customers, it helps build morale for everyone. Developers don’t work in a vacuum, or at least they shouldn’t. Business wins are rewarding for them, too.

4. Explain why things are getting done, not what needs to get done. One of the biggest mistakes I made in the beginning was to hand developers a laundry list of features that need to be built without taking the time to agonize over why each of these features is needed. When you can articulate the “why” rather than the “what,” your developers are more likely to be in sync with the company’s overall direction and vision.

I still can’t code. When I asked one of my lead developers if I should learn, he urged me to focus on delivering progress on the business side and to leave development to him. I guess if we ever wanted to run simple math equations, I could step in…or not.