Ask HN: Seeking advice from programmers for non-programmers

Great questions, Dan. Thanks for bringing them here.

An overwhelming majority of the time spent on a software startup is at the terminal, coding. If you're not doing that, then you damn well better be bringing something else of value, a lot of value, to the table. Things I'd be looking for...

- Specific domain knowledge. You gotta be the guy who says, "No, no, no, that's not the way you do in this industry. You do it this way. And you sell it this way."

- Our customers' industry contacts. You gotta be opening doors for us while we're busy coding.

- Analysis, design, testing, implementation. You should be very proficient at all the stuff on the Systems Development Life Cycle that's not coding.

- Operations. You should good at running the business while we code. This could include many things like accounting, marketing, selling, order processing, help desk, legal, etc.

We programmers are not dummies. We are working on the critical path, but we recognize that a whole lot of other stuff has to happen in order to be successful. And we want to be successful, which is a primary driver. Can you do that other stuff? Great. If not, you need to find some way to add value.

And don't forget, ideas != value. We all have a million of them. What else ya got?

The typical view of a business type by a software engineer is not pretty. It gets pretty close to, we do all the work, they do little but interfere with us, and then they take all the money. So it's an uphill battle to have a good relationship. (The _truth_ of this view varies wildly from company to company, but the perception is always there.)

See the movie "Office Space" for details. :)

Things that are a good idea: * Your technical staff is probably very smart, and not just about their jobs. Listen to them. They're particularly good at working with data. If they say that your market research doesn't sound right, even though that's your job and not theirs, it's worth going through it. Geeks are generally happy to learn things, too, so if you're actually right and can show it, we really like that too.

* Give your geeks the big picture. It really does help, because we're constantly making long-term tradeoffs, and if we know where the company is going, we'll be less likely to need to say, "Uh, we need to do a massive project for that feature, sorry!"

* Try to give clear requirements and make changes early. It's not an easy thing to ask, but a change made in planning phases is cheap. A change made when the project is in beta is expensive if not impossible. A business type giving a list of changes every day late in the project is infuriating.

* As a corollary, ask to see things early. A prototype with partial functionality is good. It's really true that a lot of times a business type just can't reasonably know what they want until they have something to play with (which is fine), so get that sooner, when things can be cheaply redesigned.

* Understand that changes aren't free. Schedules get made based on original requirements. If the requirements change, it will take longer to finish. If the deadline is fixed, you can't ask for something new without giving something up. Business types that understand this are much, much easier to work with than ones that don't, and are by far the exception.

* Programming requires uninterrupted time, like making a painting or writing an essay. If someone asks you a five minute question, it can take half an hour or more to get back in the flow of what you were doing. Try and send not-urgent questions via email, schedule meetings for the beginning or end of days, and if you can take, "Can I get back to you in 15 minutes?" for an answer, that'd help.

* Understand that these guys can, and do, do the math with respect to compensation. When I had a CEO that asked everyone to put in 60 hour weeks, and then we ended up with 3 figure bonuses when he got a 7 figure bonus at the end of the project - none of us ever respected him. If we're giving more than expected, and we will, show us some of the reward, or watch us leave. Even in a down economy, a competent techie can find greener pastures if it turns into us vs. them.

* Techies are not big on hierarchy and authority. After all, especially in a technology company, we know more about what we do than you do, and if that's the core product, there's often conflict between who is in charge and who knows about what actually is the product that pays the bills. We like to think that we work _with_ the business types, not _for_ the business types. If you project the story of doing some useful work that we don't want to do (like find buyers for our product, get us good press, find investors, stuff we want to happen but don't want to do), it'll go a lot better than if you present yourselves as 'leaders' with 'vision' and expect us to do your bidding. It's a team, and while we get that the buck has to stop somewhere and it's going to be the person with the title in the end, prima-donna VPs are just as well liked by us as prima-donna developers by you.

Someone could write an equivalent set of bullets in the other direction - yes, business people are smart, their jobs are hard, and they're often worth the salary they earn too (and certainly a lot of techies are useless.) But I'm probably not that someone. :) Hope that this is somewhat useful to you, though! I certainly have found that some business people treated technical people well and were good to work with, and others, not so much.

I agree with your points and would like to add this:

> "No, no, no, that's not the way you do ... in this industry. You do it this way."

This would be great especially when the next sentence is "And here is why: ..."

You need to develop the ability sell, advertise, publicize, make deals, etc. In short, all the things a programmer may wish to not do.

I'm the very deepest of technical kinds of guy, but on many co-working projects, I'm still the business guy, as I'm very comfortable with talking to customers, selling and negotiating work.

I'm an apps developer (I work more "end product" than services) and architect who deals day to day with system engineers (who build the tools we build upon), product managers, project managers and testers. So i'm a few steps down from yourself and also have a step "lower" in regards to system engineers (who are programmers programmers and know more about the system than the requirements, if you get what I mean). Sorry my world isn't start up world, I work for a big 'ol transport company but I hope this helps.

- How do software engineers perceive business types? - How do they come to respect or disrespect someone in this role?

Depends, but the easy trap to fall into is that they will think that you are making decisions that effect them without understanding their problems. They may not understand the sales process, they may not understand the considered risk you took when you sold that feature YOU KNOW you didn't have even though clinching that deal was strategically essential.

Therefore you really need to ensure that you communicate effectively and listen to them effectively. Most mis-placed anger is just a massive misunderstanding. You can also mitigate this by having a reference in their development-sphere who backs you up if your decisions are brought into doubt (which you need in companies that are so large that you don't have the time to give to them).

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

Slow the fuck down. I mean sure build it up a bit but don't pile on the features, it needs to be a challenge but business types seem to be very good at talking about a huge number of features which makes projects sound like death marches. Work on the core principles of the project and leave the star-gazing out of the initial conversation.

Oh and have a plan and some work done that looks like work. A lot of devs impressions from such meets are: "he wants me to do all the work". Especially with tech start-ups. Some devs don't appreciate how much work the rest of it is.

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

Listen, same as with anyone. You may need to poke them a little more than other people to get their "real" opinion sometimes but most coders are the same as everyone else.

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

Tech, interesting tech or an exciting sounding project, then money. Sometimes its the other way round.

- What do programmers think motivates business types?

Money and politics (Alpha-malism)