[dsr_]

The primary function of a legal department is to provide advice that prevents legally actionable mistakes.

This advice does not have to be sane, or efficient, or indeed have any consideration towards the interests of the company other than "prevents legally actionable mistakes". A few days ago HN saw an article about setting goals and perverse incentives. This is a simple example.

Hypothetically, someone was reviewing the Sony USA employment contract and saw that there were, perhaps, non-video-game related developments which might be valuable. Then they asked the legal department "Please supply contract terms that give us as much as possible." And after an hour or two of research, they did.

The surprising thing to me is that they tried to change language for existing employees out of cycle. If they did it during a regular review cycle, even fewer people would have noticed.

[dexen]

> The primary function of a legal department is to provide advice that prevents legally actionable mistakes. This advice does not have to be sane, or efficient, (...)

Strong disagreement. As a counterport, would you agree to the following: ``the primary function of a programming department is to crank out code. the code doesn't have to run predictably, nor be maintainable nor indeed have any business requirements. KLOC is the king.''?

When I'm programming privately in my spare time, my code doesn't need to run, be maintainable or useful or anything. But as long as I'm clocked in during office hours, my work should further company's goals, in harmony with other teams and projects. And just as much with legal departments: those should consider the overall effects of advice they give out. If not them, who else is to do such analysis -- some meta-legal department?

Been there just recently; an employment contract template prepared for my company by a lawyer was so one-sided and full of risks for potential employees, I stood up to the CEO and voiced against its proposed form. I've warned the CEO a lot of self-respecting hackers would rather give up offer than work on such conditions. The contract, while legally covering the company, would have detrimental effect on our ability to hire good hackers in the first place.

[jamesaguilar]

It seems like a lot of engineers, both here and elsewhere, have a very simplistic view of what other departments do. I've seen similar simplistic statements about design and management. I guess that's just part of human nature, to develop the view that only your work is complex or nuanced.

[brazzy]

It's not just work, and there's a name for it: http://en.wikipedia.org/wiki/Outgroup_homogeneity_bias

[anthonyb]

In this particular case though, there's not a lot of complexity or nuance, is there? It's a blanket "We own all your IP" clause in a contract.

[jamesaguilar]

Maybe . . . are you OK with the legal department assuming you are a lazy simpleton if you launch software with any bugs? Especially considering any misfeatures may have been implemented under management's direction?

[anthonyb]

I'm not sure that I see your point. Adding extra bits is more work for the legal team, and might lead to 'bugs', but a clause like this is going to lead to pissed off engineers who might leave.

To further mangle the analogy, what if I release bug free code that doesn't do what it's supposed to do?

[001sky]

Lawyers see a "mistake" and go for a landgrab. FB/Instagram TOS update was probably a similar dynamic. Legal likes to err on the side of over-reach, all other things equal.

[inerte]

But contracts itself are bound by city, state, and federal law, including civil, labor, IP, patent, etc...

Or you might get a bad lawyer or a favorable judge.

[anthonyb]

So? Contracts should be as close to your agreement as possible, and be within city/state/federal laws.

If your contract isn't accurate, it's like programming by hammering some shoddy crap together and letting the testers/users sort it out.

[zaidf]

the primary function of a programming department is to crank out code

OP didn't say the primary function of the legal department was to crank out legal language. He does say their job is to crank out advice that "prevents legally actionable mistakes".

Similarly, I think most developers at core are expected to output code that fulfill some communicated requirement.

[ProblemFactory]

This is a much better comparison.

Most programmers code to a "spec" - what they were asked to do. Only a small minority would voice their opinion if the spec is badly written or the product is not a good business idea.

[lsc]

>> The primary function of a legal department is to provide advice that prevents legally actionable mistakes. This advice does not have to be sane, or efficient, (...)

>Strong disagreement. As a counterport, would you agree to the following: ``the primary function of a programming department is to crank out code. the code doesn't have to run predictably, nor be maintainable nor indeed have any business requirements. KLOC is the king.''?

I don't see where you are getting KLOC; KLOC is rarely a metric that Programmers like. They'd choose readability, or (run-time) efficiency or something.

But yes; That's what you see. In both cases, really; I know last time I went to a lawyer for help with a AUP or privacy policy, I got something ridiculously one-sided that protected me, but would have been an absolute PR disaster to actually hand out as policy.

And yeah, I've seen programmers come up with solutions that were equally good from a purely technical perspective, but equally insane from the perspective of the whole business.

This is why managing a business is so difficult. You can't expect the lawyer to understand PR any more than you can expect your programmer to understand marketing. (I mean, sometimes you get lucky and find someone that is pretty good at both... those people are quite valuable, if you can find them.)

Actually, that's another discussion entirely. When you see the company you are working for (as a narrow specialist) doing something that is bad outside of your specialty, how hard do you try to change that? I mean, certainly, you should say "This isn't my specialty, but I think doing X is wrong, I think you should do Y" - the question then, is how hard do you fight for it. I mean, it is the person managing the company's job to choose specialists who are competent. At what point do you step out and say "Hey, you screwed it up" outside of your specialty?

[cbsmith]

That is an impression of legal departments informed by what tends to be poor staffing of such departments and/or poor management scapegoating the legal department.

I used to have a very poor opinion of legal departments until I had the opportunity to work with legal departments staffed seemingly exclusively with people who were at least as sharp as the folks in engineering. Turns out, good legal departments are as interested in solving problems as good engineering departments.

[Ziomislaw]

just like yeti, and nobody has seen any of them

[dustin]

As with most departments, legal works on a continuum.

Some coders push buggy code and some coders polish their bits endlessly. The good ones write code that meet the requirements in a reasonable amount of time and move on to the next task.

Some lawyers are strict letter-of-the-law types and some will approve anything to make the profit centers happy. The good ones balance the legal risks with the commercial reality.

Under the circumstances I'd be curious to know what the cost-benefit analysis of this change might look like. Given how seldom employment contracts are negotiated and how rarely these IP clauses are enforced, my guess is the biggest cost might be something even more intangible, such as stifled employee creativity.

[endianswap]

Do typical BigCorps require re-signing your contract during the review process? Neither of the ~300 person tech companies I've worked for have had me sign anything past the first day.

[unreal37]

Once a year there is an email that goes out saying "the law for X has changed, and so we require you to acknowledge you know this and sign Y". Basically updates to the employee handbook.