Ask HN: Seeking advice from programmers for non-programmers

In light of your experience working on startups, what advice would programmers share with non-programmers?

I'm a "business/marketing/sales" type who worked with three others (two programmers) to launch an app two years ago. We didn't make millions (or thousands) but I'd never call it a failure. I think the four of us would all say that we learned a lot about working with others, working on a startup, and our individual habits. I'm eager to apply what I learned to another startup - I've never stopped wanting to create things.

I'm not a programmer, so when I have an idea, corresponding wireframes, and a sales and marketing strategy, I'm missing the most vital component. I work a full-time job. I've considered taking classes to learn a programming language, but pragmatically, I face an uphill battle to master a very difficult skill. Moreover, it might not be the most efficient strategy. Two experts working together are more powerful than one attempting to solve for everything.

I see programmers as the most important cog in this gear. I want to improve my ability to work with software engineers, so I'm asking the HN community to contribute stories about working with what I'll call "business types." Maybe that's pejorative. But startups are often a combination of these two actors uniting to create great things. Here a few prompts: feel free to share anything you'd like.

- How do software engineers perceive business types?

- How do they come to respect or disrespect someone in this role?

- How can I best approach a software engineer with an idea?

- What can a business type do to build trust with a programmer?

- Horror stories or success stories about these two worlds coming together in startup glory or catastrophe

- What motivates programmers? Success? Personal fulfillment? Money?

- What do programmers think motivates business types?

And so on. Thanks for your time. Also, feel free to email me if you're in NYC and want to meet up to grab a beer and talk about these things.

Dan

drc617 at gmail dot com

Dan, I can't speak to all your questions, but I'll try to help out where I can. in my experience the easiest way for a techincal person to respect a "business type" is for the business guy to know a thing or two about coding and software development. This doesn't mean knowing how to build Twitter over a weekend, but you do need to know what they're going through.

With that being said, the best way to pitch an idea to a technical person (again from what I read and experience) is to build something (even tiny) yourself. It's sort of like asking a programming question: doing all of your research and going through the problem before saying "I'm stuck, please help" generates a better response.

This is the process I'm going through now. I don't have a technical background, but I'm trying my damn hardest to build something before I take the time to con some hacker to help me with building out he product :-).

From my own experience as a confirmed programmer with little interest in business, here's a couple of observations:

Programmers end up knowing a heck of a lot about the business just by virtue of needing to know how it operates in order to turn it into software. Use this knowledge. Include programmers in high-level discussions occasionally to get "buy-in" at an early stage of development (before anything like "requirements gathering" happens). This reduces the possibility for mismatch in expectations between "business people" and "programmers", which is a ready source of unhappiness for programmers and business people alike.

I've always been happiest and most productive in situations where the business people above me shield me from the other business people and let me get on with my job. So many others have observed how detrimental interruptions and rapidly shifting requirements (i.e. more rapid than 1 iteration) can be. Insulate programmers from the kinds of problems which are really no concern of theirs. Be the point of contact for other people who need programming things to happen (either as external or internal stakeholders). That's not to say that a programmer shouldn't be interacting with all areas of a business, rather, they should be able to do it in a structured way, not as a never ending stream of interruptions and fires to extinguish on an ad hoc basis.

You'll get significantly better returns on both your time and your money if you approach a developer with a conversation instead of directions.

In other words, ask questions while you're trying to figure out the best way to do things. The nice thing about most developers is that they have experience in a lot of different problem domains, and they may have solutions available that you hadn't previously considered.

Dan your points are all valid and your intent clean.

As a programmer turned business person, who (IMHO) has a decent enough grasp of both, I'll say this: you're missing the elephant in the room here.

Your approach to the problem seems to be: I have an idea and a plan, I just need someone to build it. What you should be doing though is seeking out your opposite: Programmers who have built the software, but need someone to sell it!

Programmers by their nature will solve problems that they know about on their own. They don't need any real motivation other than the problem existing for them. Where they tend to fail is extending that into a business: Do enough people share this problem, and will they somehow part with money to solve it?

The proof is all around us - there are so many free or ad-supported tools that are that way simply because the programmers behind the software have no idea how to get people to pay them for their work. (Discounting the blindingly obvious non-starters, of course)

If I were in your shoes, I'd seek out programmers working on solutions in domains that you are familiar with (key, as programmers equate domain knowledge to ability) and approach them about the art of selling their valuable creations to people that need problems solved.