Ask HN: Why can't programmers get along with business type people? - nodesolomon
======
onion2k
I believe it's largely down to short term goals versus long term goals.

From the business perspective, the company should do things quickly because
that means the jobs are more profitable, cashflow is stable, and the business
team believe that they can always find more clients even if the product is
horrible. This is the short term outlook.

From the programmers perspective the company should do things slowly because
that leads to more maintainable software, less technical debt, and higher
quality products with fewer faults. Less money comes in, but the clients stick
around for the quality goods. This is the long term outlook.

The thing that leads a company to fail is when neither side recognises is that
both outlooks are wrong. You can't run a company churning out bad code forever
because your technical team get annoyed and leave, but equally you can't build
things forever because clients don't have unlimited money.

There is a balance. If one or both sides don't understand that then the
business is not going to work well - it'll churn through developers or it'll
never make much money.

If you find a job at a company that recognises the problem and attempts to
resolve it you will be happy as a developer.

~~~
zura
Also, programmers are usually "to the point" people, while business people
love buzzwords.

~~~
gk1
Condescending remarks like this don't help the issue. A business person can
also say "Business people are down to earth, while programmers love to use
jargon that nobody understands."

There are good and bad communicators on both sides.

~~~
erik123
There is a reason why anybody who works in a job in which he faces the laws of
nature, will prefer a very precise vocabulary and will shy away from using
words that could not possibly have an unambiguous meaning. It is exactly the
opposite of what for example advertisers, politicians or business people do.
They want to keep everything as ambiguous as possible. They do this because in
their jobs they do not face the laws of nature but other people. So, it is way
less of a problem for them than for an engineer. The bridge will simply
collapse if the computations are ambiguous.

------
ownagefool
Doing things right often sounds more complicated.

Business people who don't take the time to listen and understand what they're
managing will pick what sounds like the path of least resistance.

If the buisness people cannot be reasoned with this will result in staff not
telling them what they're really spending their time on.

At this point management either a) steps back or b) buckles down and
micromanages.

Results: a) Unless there is some internal leadership within the team or you
have rather good and motivated people, this will result in the team doing what
they want, which will mostly be CV-Driven-Development or playing with the new
shiney.

b) Important steps will be skipped, likely the team will feel the decisions
are made outwith the group, yet the group suffers from the results of said
decisions. Moral of the team will go down.

This isn't specific to programmers, any time you get management that's willing
to bury their head in the sand and not understand their subject matter, you've
got this problem. Team performance will go down and if this results in
rotating non-technical management who all end up going down this road, you'll
breed programmers that simply think all managers are useless.

This is the with career managers. The problem with technical managers is they
often simply don't know how to manage. You want someone who can do both and
who actually cares about delivering value to whomever your customer might be.

------
junto

       "Oh, East is East, and West is West, and never the twain shall meet." 
       Rudyard Kipling
    

Jokes aside, I think the OP is generalizing. Personally I get on fine with the
vast majority of business people.

I don't get on with people that are incompetent. I also don't get on with
people who have a lot to learn but pretend they don't. Some of those are
business people. Some of them are fellow programmers.

Normally business people (sales) have features in mind that they know (or
think) customers want. Customers often think they want something to deliver a
business process that solves a particular problem, but might not be the most
efficient process. Programmers are concerned with the management and control
of their code-base. Often programmers cannot see the financial or business
case for a new feature request. In many cases, it isn't really their job to do
so, but it does help to understand the requirement.

As a result the two parties often have problems seeing eye to eye. However,
this is a good thing. If we agreed with everything business people wanted then
we'd have applications full of features, many of which nobody wanted. If
programmers got their way then we'd have applications that no clients would
want to use and buy.

In general each party has a niche of knowledge that the others don't. When
each party can learn to appreciate the experience and knowledge of the others,
then they can work together successfully.

------
vegancap
There definitely is a schism, and I think it's largely down to different mind
sets. Business people, have to be people people. They have to be able to
manipulate emotions and be persuasive.

Whereas programmers tend to be more absolute, more black and white. We haven't
evolved our skill sets to include persuasiveness or the businessman like
people abilities, simply because we haven't had to.

Both types have adapted to their own environments, and they're entirely
different environments.

I think a big part of the problem with programmers and business types is both
parties not understanding each other psychologically. Programmers are strange
creatures, often stubborn, highly intelligent, don't like being told what to
do.

Project managers however are highly motivated, hard-working and like to push
things forward. But you have to know how to speak to programmers, we're good
at figuring out the 'how's' but we also need to know the clear 'why's'. They
need to make the case to us instead of just telling us what to do, we like to
feel in control. But they often give orders and we get defensive.

In summary, programmers need to understand that project managers and business
people are just trying to push things forward, it's their job to try to get
things done (let's face it, a lot of us would be sat on here all day without
them). But business people need to understand what they need and be able to
explain it properly to us without giving us direct orders.

------
lifeisstillgood
They do - frequently and often. If you see a deep and non-personality based
conflict it means there is a political disjoint within the company - the
incentives for either side are misaligned - either because one or both sides
have lost contact with customers and that having to clearly and logically
spell out the disjoint is raising up a political problem the hierarchy is
unwilling to deal with.

In short, if we don't address the difference in strategy represented by the
Sales Director and the Operations Director then when the two different
strategies and priorities are given to a programmer to implement - we can
blame their kvetching on "IT guys"'instead of the two directors.

As for a solution: I would abandon Agile in such cases (!) and ask the board
of directors onto a two day coached off site where we will address the issue.
And suggest everyone polish their CVs in case.

~~~
nodesolomon
Really interesting way to look at it, I think theirs a generalisation amongst
businesses to think that the programmer is just a function rather than an
opinion/craft i.e. putting a paper inside a printer, thats it just code.

------
mcherm
They can, and they do. Sometimes they are even the same people. Where are you
getting your premises?

If what you really meant to ask is "Why do two groups of people who operate
differently sometimes operate differently?" then I think the answer is
obvious.

~~~
serf
>Where are you getting your premises

years and years of Dilbert, for one.

------
Jean-Philipe
In my experience, the gap was more between "people that do things/makers"
(designers, hackers, texters, testers, linguists, statistics people) and
"people that talk" (aka business type people, usually economy students). It
occured that the talking-only people where at some point so out of touch from
the work that actually happens, but yet in charge, and interfering with
everybody.

~~~
oftenwrong
Sounds like broken company culture, not a general truth. I've never
experienced that problem anywhere I have worked. The only problem I've seen is
that the "talkers" often do not know what is possible, and the "makers" often
don't know what the business needs to actually make money. The big moves come
when both sides get together to determine the company's direction.

------
edw519
Ego.

"Not getting along" is what happens when one believes that "I" is more
important than "we".

Once one gets beyond themselves, one can "get along". They still may not
agree, but now they've put themselves in a position to solve problems, not
perpetuate conflict.

This is also true in the general class "Why x can't get along with y," not
just for programmers and business type people.

------
petercooper
Many can. And they're the ones who make a _lot_ of money, especially if
they're consultants who align with the goals of the business. I think patio11
has written on this topic several times.

------
lmm
They can; where they don't, it's usually due to a dysfunctional organization
that means their incentives are misaligned.

~~~
tbrake
It seems to be a philosophy endemic to embedded IT: "us" vs "the business".

~~~
gk1
And it's quite visible in some of the comments here.

------
rhubarbcustard
Sometimes IT staff don't get on with people from "the business" and sometimes
people from one department of "the business" don't get along with someone from
another part of "the business". Usually stems from a lack of empathy. Often
people get so wrapped up in their own department's work that they don't stop
to consider how things are working in other departments and what pressures the
other person may be facing.

Totally frustrating for all concerned. It so often feels like everyone has
forgotten why they are there (to define, build, test and ship something) and
just spend their whole time butting heads against each other because the other
person is not doing things exactly the same way as they do.

~~~
brixon
You are not in business to "define, build, test and ship something". You are
in business to make money and the development process helps with one of the
ways to make money.

The first paragraph is spot on.

------
julie1
Ethic. First.

People constructing are accountable for being able to build on time
(announcing fair informations). Constructing/building a product (not only
coding) require the most accurate information possible and accountability.
People are paid mostly with a (lower than business) fixed amount of money.

People selling relies on assymetry of informations. They are paid on
commission (often not on the benefits but a percentage of the gross sell).

The business are hired with an incentive to lie, the builders are fired if
they do so.

Business makes all the more money that coding costs less, and vice versa. And
both coders and business are understood to be valuable and listened to. This
is a classical conflict of interest.

If you had the classical Babel tower problem, some social origin issues
(business schools are expensive), and what could be considered an unfair share
of the values regarding the costs for persons (remember a coder lose all IPs
on its works and his paid less than a business person making money on their
relation ships that they are «free» to keep), than you have also a very simple
marxist doxa (know how to make money) vs praxein (how to do) problem of unfair
repartition of value. And according to marx it results in conflict between
proletarian (coders) vs capitalists (business).

To sum up, take whatever explication you want it is a stupid logical conflict:
a power struggle (that need no symmetry) because as pointed here and there by
other contributors the incentive/goals are differents but they share the
future/resources of the same company.

------
richsin
The relationship between technical and sales is always going to be complex.

A salesperson has to not only sell, but retain customers. It's their job,
regardless of where the product is at. Customers are not easily acquired and
the position is unforgiving.

As a hybrid sales/development guy, I was always conflicted selling products
that I found myself having to convince users to stick with it on the renewal,
because the product is not performing as it should or as promised. It was the
technical side of me knowing this product is not really where it should be,
just good enough.

And the clauses, yuck!, cancellation fees to end contracts, worst conversation
to have with someone you're trying to build a relationship with. For anyone
with a conscience, it's a hard position to be in but that's what you are being
paid to do, sell. To survive you have to be at peace with the process and have
a long term outlook that the product will get better.

It's crushing to have to sell a not so great product just as much as it is
hard to push one out. I think what really makes the difference is the company
culture and shared vision. If people are not ultimately working toward the
same long term goal, there is going to be a disconnect.

------
simonswords82
I run a software house and work with programmers every day. I'm a business
type person (I guess?) in that I'm the CEO, but I'm an ex-programmer, so I'm a
weird hybrid of the two types of person you're trying to draw a line between.

I think the question you're asking leads us to look for reasons why ALL
business people can't get on with ALL programmers, which is simply untrue.
There's lots of business people around the world happily working with
programmers, and I'm one of them.

For me a good programmer is not good just because they can rattle off reams of
beautiful code and fix bugs insanely quickly. A good programmer must also be
able to prioritise their work, manage their time, communicate effectively,
understand the wider context of the work they do and much much more. These
skills outside of their core skills I refer to as "soft skills", and they're
necessary in all walks of life not just programming.

In the same way, a good business person is not a good business person just
because they can run a business that makes money. To get along with their
employees they will need to be able to delegate work, communicate effectively,
plan ahead and so on. Again, these soft skills are just as important as the
ability to make money.

So if a business man who is only good at making money works with a programmer
who can rattle off code, and they lack the aforementioned soft
skills...they're going to have a hard time working with one another. Equally,
if either of the two individuals lacks soft skills, the relationship is going
to suffer.

What's really interesting (in my experience) is that a rockstar programmer
without soft skills isn't just going to struggle to get along with business
type people, she's going to struggle to get along with everybody!

------
holograham
Misleading question since it implies that all programmers dont get along with
business types.

Clearly a subset of programmers DO get along with business types after all
most established companies have programmers working for business types.
Similarly many startup founders are BOTH a programmer and a businessperson.

A better HN question IMO would be: How do programmers and business-types
communicate better?

------
DanielBMarkham
A very generic question, so I'll put out a very generic answer.

"Business" is about making stuff people want. Business folks work with each
other -- many times under low levels of trust and high levels of risk -- to
make something people want.

"Programmers" already know what they're doing: programming. Therefore
programmers really don't care so much about what people want. Somebody is
paying them, so they program. They work inside a tight domain and usually with
a small number of people that they get to know over a long-ish period of time.

These are two vastly different universes. Business folks are always using
business skills to interact with coders: negotiation, price commitment,
conflict facilitation, and so forth. They don't care what whiz-bang you are
using to do the job. They just want the value.

Programmers are always applying programming skills to non-programming domains.
Why doesn't the business know exactly what it wants? Why do they keep hassling
us with providing estimates? How can people who are so clueless about things
actually be running the marketing department? Why do they keep pushing for
unrealistic schedules? And so on.

Very early on, organizations start stove-piping jobs. Bill is a CPA. He should
only do accounting stuff. Joe is really good with people. We're just going to
have him do pre-sales. Amit is a database guru. We'll have him do all the DBA
work. We need to have some defined roles around here! Where's my job
description?

This seems to make sense, but over and over again, this logical separation of
concerns comes back to bite. After a year or so of doing just the "DBA work",
whatever that is. He starts viewing things not involving database
administration as a waste of time.

You keep that up over many years, and allow the company to grow? You've got a
bunch of folks who all like the folks they interact with and see everyday, but
are deeply suspicious and completely clueless about everybody else. Not a good
thing.

------
krmmalik
I'm with onion2k on this one. It's mostly do to with differing mindsets and
world views. I'm not a coder, I'm in Digital Marketing, but yesterday I had a
meeting with management regards their Google Ads campaign. A simplistic
overview of the dilemma I had yesterday: We need to collect data on how well
their site is performing for which we need to run trial campaigns so that we
can analyse data. The management team see it purely as an expense and don't
see the value of the "learning" exercise. That causes a struggle. Now the
result is that the campaign that will be run is already compromising the
quality of the learning that we can do, and this because the "Business" people
have to be answered to.

------
darklajid
For me the division is mostly centered on quality.

The sales I'm working with want me to ship whatever, ship fast.

I want to ship quality.

Since money always wins, this usually ends with me giving in, feeling bad
about it and .. blaming the sales people for being short-sighted/focused on
the immediate return only.

~~~
cturner
Something to keep in mind about quality - sometimes programmers spend ages
doing something in a way that seems like the right way, and the end result is
either unimpressive, or a disaster. That destroys goodwill.

A project manager who had a history of working with unreliable developers may
be drawn to a mindset of only trusting near wins, or even distrusting
elegance-based arguments.

------
lukasm
It comes down to 3 things: 1\. Communication 2\. Different incentives/goals
3\. Modus operandi

@1 Tech people speak tech - no marketing bullshit. Business people often don't
understand what programmers are saying and it causes the frustration. Mental
models are skewed by marketing and sales.

@2 Programmers want to build things properly, use cool stuff and develop
skills. Business guys want to meet their quarterly targets.

@3 Business people want to solve problems with money. A lot of problems cannot
be solved that way. They have a internal voice whispering "reduce cost and
increase revenue", but it doesn't say "technical debt".

PS This is not binary. Programmers can behave like business types and vice
versa.

------
whizzkid
Here are my 2 cents, since i am involved in both management and programming.

Developers and programmers are often right about their opinions. BUT, that
opinion is not always the output that company wants. Here is a simple example;

\- Company wants to get rid of one of their products. (not enough sales, a new
better product is planned, etc. )

\- Dev lead wants to have extra resource for his/her team because of deadlines
etc.

\- It gets rejected

\- Dev lead warns the company that releases will be delayed and customers will
not be happy (true)

\- Manager doesn't do anything about it because product's future is already
decided.

\- Dev lead is not happy about this decision.

It is kind of hard to satisfy both management and employees at the same time
but that is the nature of it.

------
kourt
One source of conflict is that many "business type" tasks/projects can be
fairly easily time-scoped: "a report about opportunities for our product in
Poland" can be a 5 minute comparison of populations, or a multi-year PhD
dissertation.

Technical work often has a more rigid "minimum viable solution": a civil
engineer can't just give up on a bridge halfway over a river, nor can he say
"I just skipped the wind loading calculations and hope the school buses don't
run on windy days." Some types of software (especially embedded e.g.,
aerospace and automotive) have similar concerns about safety and warranty.

------
unknownBits
Business people are only in for the money (and power). Programmers are little
artists interested in something that in it's core has nothing to do with
money. Programming is about a passion for creating things with technology. The
main problem is that most people are taught, and still think, that money makes
things possible, while in reality money is the most destructive thing mankind
has ever encountered. Money hinders development in so many ways, not to speak
of the horror it causes like: wars, poverty, abuse, pollution and much more.
Business people do not understand this.

------
normloman
Sure they can. In fact, many programmers are business people.

That said, there are plenty of conflicts between programmers and their
managers. Usually, it's because the management doesn't understand programming.

------
mooreds
Huh? Working means getting along with different kinds of people.

I think that if you aren't getting along with a business person, it is
incumbent on both of you to discover what the disconnect is. What are you each
missing? Maybe it is an understanding of technical limitations on their part,
or a blind spot about the business on yours.

Except in the case of ill will on someone's part, discussion between adults
should resolve the problem. If there's ill will, that's a good job to leave.

------
jeffasinger
When I've seen problems before, it's usually due to a lack of mutual respect.
Either you have the business people thinking of the programmers as relatively
useless nerds who can't do anything right on their own, or you have the
programmers thinking that the business people basically sit around and do
nothing.

I've never seen any real problems if both sides realize and understand that
what the other side is doing is important and not easy.

------
LBarret
Looks at what they do, and you'll find the source of their biases.

A coder works with objects that are between math and infrastructure. From
math, he gets the logical reasoning. From infrastructure, the long term need
for solidity. A coder is also much product oriented.

Bizdev works with more fluid concepts (perception and human psychology) and
focus more on the cash flow. Time is essential in business, a good product
late rarely succeed.

------
crapshoot101
This is silly, and untrue. Any business where this is a case,is a business
that is doomed in the first place - the best people get along fine across the
spectrum.

------
k__
I don't get along with most people I meet and their behaviour seems silly to
me.

Like the cool guys at school back in the days.

------
alien3d
For me,im implement accounting.most customer want to follow their rule.no gap
no frs or whatever.just request.customer need third party accountant to
consult so smooth project.i see havoc in oracle e business and baan
implementation.internal staff request non functional and destroy the good base
erp.their vendor everyday meeting and meeting and day by day programmer left..

------
renas
Maybe because business people request "non-sense" stuff, by non-sense I
actually mean, non-logical, not fitting the system.

~~~
corin_
I hope you're being tongue in cheek, because if not you've missed the point
that while you think that, business people will think exactly the same about
you from the other side.

------
Daviey
Bit of a generalisation...

------
qwerta
But we can get along with business people, it is opposite way around:

b> How long it will take?

p> About 2 months.

b> We need it in 1 week.

....

------
andrewstuart
Aspergers.

~~~
lutusp
Asperger's is gone, and not lamented.

[http://www.nytimes.com/2009/11/03/health/03asperger.html?pag...](http://www.nytimes.com/2009/11/03/health/03asperger.html?pagewanted=all)

