

Ask HN: Seeking advice from programmers for non-programmers - twelvedigits

In light of your experience working on startups, what advice would programmers share with non-programmers?<p>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.<p>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.<p>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.<p>- How do software engineers perceive business types?<p>- How do they come to respect or disrespect someone in this role?<p>- How can I best approach a software engineer with an idea?<p>- What can a business type do to build trust with a programmer?<p>- Horror stories or success stories about these two worlds coming together in startup glory or catastrophe<p>- What motivates programmers?  Success?  Personal fulfillment?  Money?<p>- What do programmers think motivates business types?<p>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.<p>Dan<p>drc617 at gmail dot com
======
icey
A problem I've seen from _both_ sides of this fence is that one side tends to
over-simplify what the other side needs to do to get something done.

A business guy may say "oh just slap this together and you're done", while a
software guy might say "just go get some sales and we're golden".

I think taking a few minutes to find out the actual effort required to make
something happen can go a long way; for both business people and software
people.

The other thing that I see happen a lot is that business people tend to want
to say "yes" to everything, while software people tend to want to say "no". It
makes sense in context, business people want to do whatever it takes to make
successful sales, while software people generally want to keep a manageable
feature set (they also tend to know the full problem domain a little better
than most of the business people they deal with; at least from the technology
front).

Of course, these are all generalizations, so you have to take them with a
grain of salt.

~~~
sidmitra
>is that business people tend to want to say "yes" to everything, while
software people tend to want to say "no"

That is so true, and i see that every single day. I guess NO is a bad word in
marketing/sales, whereas it's actually a pretty good one in the dev world. It
usually means, less feature bloat, lesser maintenance.

------
run4yourlives
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.

~~~
mullr
Can't agree with this enough. I'm a programmer, and I solve lots of problems.
Build lots of things. But not only do I not know how to sell anything, I don't
even know anybody who knows how, or know how to meet anybody who knows how.
And there's no way it's just me.

------
Kirby
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.

------
jcoby
I'm a programmer by trade but I also have my own startup and have a decent
amount of business experience. I'm writing this from a programmer's
perspective though.

> How do software engineers perceive business types?

The idiots who constantly make bad decisions that cause programmers to work
even harder and miss sleep.

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

"We promised we'd implement this feature to a _very important_ client by next
week. How hard is it?" Generally for a feature that is esoteric and nearly
impossible to implement. And usually for a client that doesn't generate much
revenue.

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

Talk to them. Ask their opinion. Most programmers love to know details,
backstory, and to be part of the process.

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

Talk to them. Programmers _hate_ to be asked or told to do something without
knowing why. You'll generally get a better result if they know why the feature
needs to be added instead of just telling them to put a button here that does
this.

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

I was employee #2 at a web startup that was barely in the black (perhaps just
solvent) after about 5 years in business. I ran IT. The owners brought in an
angel who invested a nominal amount of money for a ridiculous amount of
ownership (47.5%). The angel brought in a CEO. The CEO brought in salesmen. I
hired a few programmers and a network guy. The salesmen brought in even more
salesmen. The CEO brought in someone to oversee me.

The CEO was a "big-bang" kind of guy so he immediately started pitching the
product to anyone he could find. The product wasn't ready and hit all sort of
problems. Lots of infighting and little political factions starting springing
up between the new guys and the old guard. Both sides thought each other were
idiots. We knew the market and the new guys had no experience with either web
or the industry we were in. We knew how to save money and generate profit and
they knew how to spend it.

Within 2 years there were at least 8 VPs in a 40-person company (only about 20
of them worked full-time onsite). By the time I left, the company had 60+
people on payroll, with about 10-15 of them being IT. There were probably a
dozen VPs (I lost count and didn't care anymore), and was burning about $7M/yr
with no sign of turning a profit. The "business types" are still figuring out
how to make money, still over promising and under delivering, and just about
everyone there hates the place.

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

Challenge and accolade. A good programmer loves to solve puzzles and wants to
be acknowledged for his or her work. Very few things are as deflating as
busting ass on a feature that someone else gets all credit for. Programmers
love toys- this includes fast hardware and good equipment. If your programmers
don't have dual screens and a computer built in the past 12 months, something
is wrong.

> What do programmers think motivates business types?

Ego. Resume building. Money. Job titles.

------
tc
Having spent time on both sides, I'll offer one pro-tip:

 _Never_ comment on how difficult something should be. Just don't do it.
Physically restrain yourself if necessary from saying, "but it's only doing X,
it _shouldn't_ be _that_ difficult." [1]

If a smart technical person says that it's going to be hard, then it is going
to be hard. If it really is a blocking issue for you, you instead need to
bring your team into the bigger picture and ask, "At the end of the day, we're
trying to solve a problem like X. How can we permute X into something we can
solve more easily?"

[1] Only if you are technical can you get away with this. You'll still be
wrong if the other person has thought about it quite a bit more than you have,
but at least you'll be able to understand and _appreciate_ the explanation
they'll throw back at you about what deep complication makes the problem hard.

------
mdakin
Your choice of the word "cog" to represent a programmer and "gear" to
represent a team indicates you might be internally (to your mind) objectifying
the people involved with your potential projects. I could see such an internal
objectification causing various problems with your interactions with the
"cogs/gear" in various ways during a project. You can quickly lose someone's
respect if he learns that you think of him as a replaceable part of a soulless
machine.

A problem for "business types" is that they are _trained_ to think of people
as "human resources." This is probably a bad idea on any scale of
team/organization. But it's an absolutely horrible idea w.r.t. the small-scale
teams of which startup companies are made.

------
gdp
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.

------
natch
I was a non-programmer, and I wanted a program written. Nobody was going to
write it, and I didn't have the money to pay someone to write it.

So what did I do?

I learned to program, in order to write that program. It took a while, but it
was worth it. And it turned out great. And years later I'm still learning. The
learning never stops. That is a good thing, not bad.

I would advise anyone to not think of themselves as a "type" but instead to
figure out what you want to do, and do it. It might take some hard work. But
again, it is worth it.

So how do I perceive non-programmers? They are just people who either have not
discovered the concept of what programming can do for you, or they have
discovered it but have given up on their own ability to learn (fallen into the
"type" misconception). Kind of sad either way.

------
maudineormsby
Also interested in hearing people's thoughts on this, as a "demand side" guy
who asks programmers to do stuff.

My advice, FWIW, is that talking to and really trying to understand the
problems faced by the engineers/developers working for you goes a VERY long
way. Typically, they just want to know that someone is aware of their issues
and is working with them, not against them.

Not a unique problem though - that's how all management needs to function.
Although the technical barriers in programming can be daunting (as I think the
OP notes).

~~~
icey
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.

------
christonog
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 :-).

~~~
roam
While I truly applaud you for trying to build at least something yourself, I
have to ask why you think you need to do that? I, as a programmer, wouldn't
expect you to build a prototype. What I _would_ expect is a very detailed list
of use cases that shows you've thought this through.

Sure, that's not something you can simply show in a five minute conversation,
but mockups are great for this purpose.

~~~
christonog
As I explained with gdp, I believe you need to know some bit of the technical
side of things to succeed in a tech. start-up. To me it just makes sense. I
have tried the mock up approach, with not so great results. So right now I'm
trying a different approach.

I love solving problems, and I like making things. In my learning I've come to
enjoy doing this through coding, but I know that my skills currently won't fly
in scaling a startup.

------
endtime
I'll answer the ones I have answers for:

\- How do software engineers perceive business types?

The stereotype is that you guys are a bit jockish, and/or that you tend to
have good social skills but less hard/technical skills.

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

I'll respect a business person who makes the effort to understand the
engineering (and I _don't_ mean humoring me by asking for a one hour
programming lesson - it's more important that you understand technical issues
on a high level), as well as give comprehensible and straightforward answers
to any questions I have about his. A smart programmer has to know when to put
business before his sense of engineering elegance or desire to make a cool
product, and if you can be sensitive to how hard/frustrating that can
sometimes be, so much the better.

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

Try to understand what I'm doing and what's hard about it, and explain to me
the same about what you're doing.

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

Depends, but I'd say success and money in a startup are nearly, if not, the
same thing. Desire for personal fulfillment is probably a little more common
among programmers than business types, but that might be my own stereotype of
business types talking (though I knew a lot of business students as an
undergrad, and dated one for two years, so it's not totally unjustified).

\- What do programmers think motivates business types?

Money.

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

Earn respect by investing not only in your product, but in your programmers.
If you're a carpenter, you'd think your boss was crazy for asking you to drive
nails without hammers or a nail-gun; and yet, this is how programming
environments sometimes operate, causing consternation.

Earn disrespect by treating programmers like cogs. Do not ever assume that you
can simply replace one programmer with another; there is an absolute chasm
between the skills of the best and the worst. One way to judge your
programmers is in adaptability; do they at least seem willing to tackle
anything you throw at them, or do they not really have a clue how to start
most of your ideas?

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

Do not make any assumptions about how simple the implementation could be.
There are hard things that sound easy, and vice-versa. At the same time, be
prepared to deconstruct your idea to say "well what if we only did X and Y";
you may be surprised how different the answer is.

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

Be detailed; communicate without filters. There's nothing worse than being
asked to drop everything to provide one or two tidbits of information
"immediately", only to find out later that the wrong question was being asked
and that the priority wasn't really accurate. Heck, if you have to tell the
programmer your 3-year plan for the product, do it; that may affect how the
implementation proceeds.

Be flexible. Programmers will be productive at the weirdest times. If you see
someone who comes in late and works for 12 hours straight, then takes a day
off, they could still be the most productive software developer you've ever
seen. Even if we aren't actively working on an idea in front of a computer, we
are often putting it together in our heads. Perception is not reality in most
cases. Having said that, _do_ demand evidence ( _simple_ documentation,
occasional updates, and definitely prototypes).

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

I want to feel like my projects are useful. I want to have the freedom to
design, and not feel "stuck" with any bad decisions.

Money is only important enough for me to live comfortably (I don't need a
mansion or a yacht). On the other hand, if it became clear that someone who
contributed very little was going to be showered with millions from my ideas,
I'd definitely want my cut.

 _\- How do software engineers perceive business types?_

As a necessary evil. :) Software is relatively easy to distribute, so there
isn't much to prevent people from acquiring your product. On the other hand,
there is a lot to prevent them from _finding_ products, so marketing is quite
important. Not being sued is important. :)

------
Quarrelsome
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)

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

Back up a step. Why are you approaching said engineer with that idea? Yes, I
know that you want said engineer to build it, but why should anyone build that
idea and not some other idea?

I'm sure that you've got good supporting arguments, but if you don't provide
them, you're indistinguishable from the vast majority, who have nothing.

It's okay if there are holes in your arguments IF you admit them and talk
about them. If we find significant holes that you don't tell us about, our
experience tells us that there are additional problems and that you're
incompetent and/or deceptive. That's not likely to lead where you'd like to
go.

In short, tell us everything. We'll ignore what we don't need to know.

------
maxcap
Your prompts are very broad and a discussion based on them is open to
generalizations that may not apply to the people you eventually end up working
with.

You are far better off discussing these questions with the people you intend
to have around you when you start your new venture.

------
maxklein
Be organised as hell and keep things under control. The programmer will
appreciate when things are running smoothly, and all he has to do is fill in
the correct spots and then get to coding, and does not have to worry about if
articles are out, if there are spelling errors on pages or stuff like that.

Be the one that stays calm, keeps the processes running smoothly, keeps on
doing analysis to make sure things are running on the right path.

When the programmer feels he is in a smoothly running engine, then he will
need you around. When you start discussing things all the time and panicking,
he will want to step into your territory to help out, and then he will start
worrying and become a lot less productive.

------
DannoHung
Show your tech guy your deliverables; what you're actually adding. He'll be
able to point and say, "I did this and this and this and the proof is right
there." You should be able to do the same.

If you're talking about compensation, make sure that everything is clear and
out in the open and that there is no ambiguity about terms or conditions. This
is really just a general rule for not getting in a spat.

Know how to set priorities, keep your scope focused, and explain the business
reasons for any change you're driving. Little else is more upsetting than a
nightmarish task seeming important but really being inconsequential.

------
fizx
\- How do software engineers perceive business types?

Business types are people. I evaluate on character plus effectiveness. When
forming an opinion, I generally look at their past success, their history of
screwing people over (or not), and their smarmyness (or not), as well as their
ability to communicate.

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

See above.

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

With a referral and/or some demonstrated way that you've done a ton of
homework, and you understand what you're getting into.

Also, please demonstrate respect and partnership. "We need a coder for this",
while not overtly disrespectful, implies that you see your technical partners
job as one-dimensional.

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

Good referrals, pay invoices ahead of schedule, don't change scope often or
arbitrarily.

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

Rather not share right now.

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

Some combination. I think most of us need adequate levels of all of the above,
with one factor we can point to as being excellent.

\- What do programmers think motivates business types?

Money, ego.

------
jeromec
It may be helpful to remember that programmers look at things logically.
That's why I'm no good at sales. I look for direct paths and solutions, and
understand yes/no, not negotiations. I tell you this to show how/why I have
respect for effective marketers. It's a bit like magic to me because my brain
doesn't work that way (so you see how the tables can turn).

As for the questions, think about it in terms of any business relationship.
Show that you can and will bring value to the table, and follow through on
promises. Programmers do hard work; we would appreciate and respect a
"business guy" walking back in the door with tie crooked, hair tousled and
perspiring after a day working their marketing magic.

------
auston
_WARNING: THIS IS MY PERSONAL OPINION_

1\. Uninformed.

2\. By not consulting on "business decisions" which are actually mostly tech
decisions.

3\. Make sure you have AS MUCH COMPLETE as you POSSIBLY CAN - things like
idea/strategy/wireframes/html mockups/product alpha/prototypes/customers who
have intent to use product if it exists/realistic 1st year numbers/plan on who
is getting merchant account/incorporating/vesting of stock/who is doing
accounting/what is the bare minimum for v0.5 of product.

4\. Be honest, open & encouraging. Mostly honest & open though.

5\. None

6\. Money & Recognition

7\. Money & Recognition

------
gord
learn to program - a bit of lisp, a bit of C [not to do it but to appreciate
the mindset]

Mentioning VB, Microsoft or Clearcase are very uncool and will turn away any
talented people you might want to learn from, hang out with, hire or become
co-founder with.

Can I suggest not use the words 'cog ... gear' - which suggests you have a
worldview [shared with most recruiters] who think beautiful work is something
that takes no human passion.

Learn a little bit about aspergers... when approaching someone who is
creating, perhaps quietly put a post it note such as "lunch @ 2, sushi ?" just
within view while saying nothing.

A useful blog to read might be 'Rands in Repose'

If you've worked to launch an app, you must know all this already? Jump in
again, find some smart guys and build another startup. Then write a book on
the topic and become famous on the talking circuit... you're probably ahead of
the game already.

------
gte910h
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.

------
edw519
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?

~~~
kirubakaran
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:
..."

~~~
Confusion
There isn't always a 'why' that makes sense. A lot of ways in which things are
done are determined by their history, not by what one would expect to work
best. Moreover, business/selling is not an exact science, so you should not
expect the salesman to provide reasons that make rational sense.

So, from the other side of the fence, you need to make sure your engineers
understand that.

