6 ms·

Ask HN: Why can't programmers get along with business type people?

30 points by nodesolomon 12y ago

renas 12y ago
Maybe because business people request "non-sense" stuff, by non-sense I actually mean, non-logical, not fitting the system.
- deleted 12y ago
  [deleted]
- corin_ 12y ago
  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 12y ago
Bit of a generalisation...
lifeisstillgood 12y ago
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 12y ago
  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.
- watwut 12y ago
  I do not think a day or two somewhere can cure organizational dysfunction. You need to change the way people are working, incentives and processes. They will fall into the old patterns otherwise, no matter how motivated everyone after those two days will be.
lmm 12y ago
They can; where they don't, it's usually due to a dysfunctional organization that means their incentives are misaligned.
- tbrake 12y ago
  It seems to be a philosophy endemic to embedded IT: "us" vs "the business".
  - gk1 12y ago
    And it's quite visible in some of the comments here.
mcherm 12y ago
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 12y ago
  >Where are you getting your premises years and years of Dilbert, for one.
rhubarbcustard 12y ago
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 12y ago
  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.
Jean-Philipe 12y ago
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.
- justincormack 12y ago
  Business type people make businesses.
- oftenwrong 12y ago
  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.
vegancap 12y ago
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.
andrewstuart 12y ago
Aspergers.
- andrewstuart 12y ago
  To the down voters, you may not like the truth but.....
- lutusp 12y ago
  Asperger's is gone, and not lamented. http://www.nytimes.com/2009/11/03/health/03asperger.html?pagewanted=all http://www.nytimes.com/2009/11/03/health/03asperger.html?pag...
darklajid 12y ago
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 12y ago
  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.
- brixon 12y ago
  How many products (physical or virtual) have absolute quality? What is the price point and competitive advantage of your product? Software is no different than physical products in balancing quality with price. The only advantage software has is that we can improve the quality later. If people buy your product because it has the fewest bugs and is more resilient when things go wrong then push hard on the sales team. But if your product gets sold due to it looking nice and having a few wiz bang features then give them some slack.
onion2k 12y ago
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.
- kourt 12y ago
  bad code forever because your technical team get annoyed and leave And the effects of technical debt and bad code will eventually result in slow iteration and poor product quality which will eventually become visible to customers.
  - voidlogic 12y ago
    This x1000. I think that OPs sentence above was the only off part of their assessment, most was spot on. When I was a consultant integrating niche specific 3rd party apps, where even the "major vendor" was often a pretty small operation. It was not uncommon to see this happen. Slow releases, years of minor updates, with "the big update" always on the horizon. Inability to come out with a 64-bit version, etc. All very common and signs of poor project management, technical debt, or most likely, both. Sometimes we would be resolving issues with their "support engineers" only to realize they had like 2 developers (one of which we were talking to) and a whole team of sales guys.
- waps 12y ago
junto 12y ago
"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.
ownagefool 12y ago
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.
petercooper 12y ago
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.
kourt 12y ago
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.
alien3d 12y ago
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..
krmmalik 12y ago
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.
edw519 12y ago
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.
normloman 12y ago
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.
qwerta 12y ago
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. ....
crapshoot101 12y ago
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.
mooreds 12y ago
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.
simonswords82 12y ago
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!
lukasm 12y ago
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.
jeffasinger 12y ago
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 12y ago
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.
cheery 12y ago
So why stereotypical programmer can't get along with stereotypical business person? That's because they're stereotypes. Stereotypical programmer is a freedom-fighter. They might breach into "locked" systems. They Love to share things. They love quality. A stereotypical business person puts a price for everything and cares only about optimizing profits. These stereotypes are naturally in conflict. Keep in mind stereotypes do not accurately reflect reality.
whizzkid 12y ago
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.
unknownBits 12y ago
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.
julie1 12y ago
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.
DanielBMarkham 12y ago
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.
k__ 12y ago
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.
holograham 12y ago
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?
richsin 12y ago
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.

30 points by nodesolomon 12y ago

renas 12y ago

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

deleted 12y ago
[deleted]
corin_ 12y ago
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 12y ago

Bit of a generalisation...

lifeisstillgood 12y ago

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 12y ago
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.
watwut 12y ago
I do not think a day or two somewhere can cure organizational dysfunction. You need to change the way people are working, incentives and processes. They will fall into the old patterns otherwise, no matter how motivated everyone after those two days will be.

lmm 12y ago

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

tbrake 12y ago
It seems to be a philosophy endemic to embedded IT: "us" vs "the business".
- gk1 12y ago
  And it's quite visible in some of the comments here.

mcherm 12y ago

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 12y ago
>Where are you getting your premises years and years of Dilbert, for one.

rhubarbcustard 12y ago

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 12y ago
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.

Jean-Philipe 12y ago

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.

justincormack 12y ago
Business type people make businesses.
oftenwrong 12y ago
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.

vegancap 12y ago

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.

andrewstuart 12y ago

Aspergers.

andrewstuart 12y ago
To the down voters, you may not like the truth but.....
lutusp 12y ago
Asperger's is gone, and not lamented. http://www.nytimes.com/2009/11/03/health/03asperger.html?pagewanted=all http://www.nytimes.com/2009/11/03/health/03asperger.html?pag...

darklajid 12y ago

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 12y ago
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.
brixon 12y ago
How many products (physical or virtual) have absolute quality? What is the price point and competitive advantage of your product? Software is no different than physical products in balancing quality with price. The only advantage software has is that we can improve the quality later. If people buy your product because it has the fewest bugs and is more resilient when things go wrong then push hard on the sales team. But if your product gets sold due to it looking nice and having a few wiz bang features then give them some slack.

onion2k 12y ago

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.

kourt 12y ago
bad code forever because your technical team get annoyed and leave And the effects of technical debt and bad code will eventually result in slow iteration and poor product quality which will eventually become visible to customers.
- voidlogic 12y ago
  This x1000. I think that OPs sentence above was the only off part of their assessment, most was spot on. When I was a consultant integrating niche specific 3rd party apps, where even the "major vendor" was often a pretty small operation. It was not uncommon to see this happen. Slow releases, years of minor updates, with "the big update" always on the horizon. Inability to come out with a 64-bit version, etc. All very common and signs of poor project management, technical debt, or most likely, both. Sometimes we would be resolving issues with their "support engineers" only to realize they had like 2 developers (one of which we were talking to) and a whole team of sales guys.
waps 12y ago

junto 12y ago

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

ownagefool 12y ago

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.

petercooper 12y ago

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.

kourt 12y ago

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.

alien3d 12y ago

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

krmmalik 12y ago

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.

edw519 12y ago

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.

normloman 12y ago

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.

qwerta 12y ago

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

crapshoot101 12y ago

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.

mooreds 12y ago

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.

simonswords82 12y ago

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!

lukasm 12y ago

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.

jeffasinger 12y ago

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 12y ago

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.

cheery 12y ago

So why stereotypical programmer can't get along with stereotypical business person? That's because they're stereotypes. Stereotypical programmer is a freedom-fighter. They might breach into "locked" systems. They Love to share things. They love quality. A stereotypical business person puts a price for everything and cares only about optimizing profits. These stereotypes are naturally in conflict. Keep in mind stereotypes do not accurately reflect reality.

whizzkid 12y ago

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.

unknownBits 12y ago

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.

julie1 12y ago

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.

DanielBMarkham 12y ago

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.

k__ 12y ago

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.

holograham 12y ago

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?

richsin 12y ago

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.