FMLA Amendments Signed - Leave for Relatives of Military

Congress passed FMLA amendments expanding FMLA protection leave taken under certain circumstances by relatives of soldiers. We covered the amendments here. The president initially vetoed the law in which the FMLA amendments were contained. Now he has signed them. They are included within HR 4986, as section 585. (It's a big bill, concerning a number of issues related to defense; so, please scroll to that section). We will be writing an article regarding compliance with this new law over the next couple of weeks.

Greg

Court of Appeal: Stock Options OK Form of Payment

The Court of Appeal upheld a stock option plan against a claim that it worked illegal forfeitures under the California Labor Code. The Court held that Citigroup's stock option plan was valid because, in a "two-step" transaction, it gave employees cash with the right to buy options at a heavily discounted price. The catch was they forfeited it if they did not remain employed.
The Court held this plan, as drafted, was not an illegal forfeiture.

The Court also noted even if the options were granted directly, the forfeiture would be valid because it was express and clear.
Of significance to wage and hour wonks, like me, the court also addressed whether payment in stock options was a violation of the Labor Code's requirement of the form of payment. I once posited that issue to a DLSE official and received a chilling answer. But no. The court said Section 212 does not apply when payment is made in stock options. That should give everyone a sigh of relief. ::Sigh::: The case is Schachter v. Citigroup and the opinion is here.

Ninth Circuit: Cab Operators Were Employees, Not Independent Contractors

When a union organizes an employer's workers, the National Labor Relations Act governs the union election. Independent contractors cannot be organized because they are not considered "employees." When an employer claims that workers are independent contractors as a defense to union organizing, the NLRB (and a reviewing court) will apply federal law. In NLRB v. Friendly Cab Co., opinion here, the Ninth Circuit held that Friendly's cab drivers were employees, not independent contractors, and therefore were properly organized by the union. The opinion thoroughly discusses the criteria federal courts apply to independent contractor analysis in the labor law context.

February 1 Is OSHA Log Day!

February 1 is when all good employers' thoughts turn to their OSHA 300 logs.
Here is a helpful reminder from our friends at the California Chamber of Commerce.

Greg

California Supreme Court: No Accommodation for Medical Marijuana

The California Supreme Court decided today that there is no duty under the Fair Employment and Housing Act to "reasonably accommodate" medical marijuana use as treatment for a "disability." The Court also held the plaintiff could not state a claim for wrongful termination in violation of public policy based on California's Compassionate Use Act, aka Prop. 215. The Legislature may pass a law amending FEHA to require accommodation of medical marijuana use, assuming the Governor would sign such a bill. Or, another initiative may be presented to the voters. Until then, though, employers may deny employment based on positive drug tests for marijuana, medical or otherwise. The case is Ross v. RagingWire Telecomm., Inc. The opinion is here.

I admit this is an especially nice post to write, considering I principally authored the employer's briefs at the Court of Appeal and in the Supreme Court. Shameless plug, I know, but this has been a long time coming! And a thank you to my former colleagues Marlena (Ct.App.) and Tim (S.Ct.) for their hard work on the briefs, and to my former partner, Rob, for arguing at the Supreme Court.

Greg

No Workers' Compensation Benefits for Mean Employee

So Verga is a United Airlines employee. She is tough on her co-workers. They resent it and are mean to her. Verga files a workers' compensation claim for "stress" caused by the co-workers' "disdain." The Court of Appeal, agreeing with the Workers' Compensation Appeals Board, held: "No benefits for you!"

Here is the gist of it:

The Workers’ Compensation Appeals Board (the WCAB) concluded that Rosemary
Verga was not entitled to compensation for psychiatric injury while employed by United Airlines. According to Verga, her psychiatric injury was the result of harassment and persecution by her supervisor and co-workers. However, the WCAB found “the true fact remains that [Verga] was not actually subject to harassment or persecution, she instead brought upon herself the disdain of her co-workers” because Verga was “a difficult person to get along with”; she was impolite, unpleasant, and co-workers “never knew when [she] might get upset.” The WCAB held: “That disdain is not an actual event of employment” within the meaning of the statute. [par.] We issued a writ of review and shall now affirm the WCAB order.

The case is Verga v. WCAB and the opinion is here.

More Discrimination Charges May Be Filed?

The California Department of Fair Employment and Housing has implemented a new, online system for beginning the process of filing discrimination charges. Read the press release here. The online system actually is a way to set up an appointment for intake. Previously, employees had to scheduled those appointments over the telephone during the day. When they're at work. And when the DFEH representative is available to answer the telephone. The new system does not automate the actual charge-filing process. So, employees who were discouraged from making an appointment during the workday will now be able to do so when they're surfing the internet. That will lead to more appointments scheduled. But the intake process will then continue in the old-fashioned way. So, it's unclear how many new charges will actually be filed as a result of the new system.

Have a nice weekend.

DGV

Directors Not "Employees" under Federal Law

The Board of Directors of a non-profit did not count as "employees" under the federal ADEA or ADA. Media Center provides public access programming in Nevada. One of its employees sued under ADEA and ADA for age and disability discrimination. The district court dismissed the case because Media Center did not have sufficient "employees" when one disregarded the directors as well as certain volunteer "producers."

As the court pointed out, whether the directors count as "employees"

is governed by the United States Supreme Court’s analysis in Clackamas
Gastroenterology Associates, P.C. v. Wells, 538 U.S. 440 (2003). In Clackamas, the Court addressed whether physicians that were also directors and shareholders of a clinic were employees for purposes of the ADA. The Court noted that Congress had intended the word “employee” to describe “the conventional master-servant relationship as understood by common-law agency doctrine.” Id. at 445 (internal quotation marks and citation omitted). The Court then described six factors relevant to determining whether a director is an employee:

• Whether the organization can hire or fire the individual or set the rules and regulations of the individual’s work
• Whether and, if so, to what extent the organization supervises the individual’s work
• Whether the individual reports to someone higher in the organization
• Whether and, if so, to what extent the individual is able to influence the rganization
• Whether the parties intended that the individual be an employee, as expressed in written agreements or contracts
• Whether the individual shares in the profits, losses, and liabilities of the organization.

Applying this test, the Court held directors are not "employees." The case is Fichman v. Media Center and the opinion is here.

DGV

Ninth Circuit STAYS Injunction, Allowing SF Health Care Ordinance to Go Forward

Stay with me here.....

In late-December, the U.S. District Court enjoined San Francisco's Health Care Security Ordinance. That meant that it could not go into effect. Here is our post on the injunction.

The City appealed. Typically, the injunction remains in effect until the appeal is over.

But the City decided to ask the 9th Circuit Court of Appeals to stay the injunction pending resolution of the appeal. That is, the City wants to implement its law that the district court says is illegal.

No way, right? I mean if the stay issues, then the law goes into effect. That's not fair. If the law is later found preempted by the court of appeals, who is going to pay back all those employers who were subjected to an illegal law? (No one.) So, of course, the Ninth Circuit would not engage in an exercise of raw power and basically pre-decide an appeal to facilitate San Francisco's universal health care law, right?

Wrong. The Ninth Circuit just granted the stay based on an expedited motion and an argument on January 3. In granting the stay, the Court basically decided that the city is going to win on appeal. The panel could not have been much stronger in its language. Here is the opinion.

Here's a question the court did not tackle: What's the point of having an full appeal procedure when the court is willing to say, based on an appeal that took less than a week to file, argue, and decide, that there is a "strong likelihood" of reversal? Not much. So, if you ever want to see how well your appeal is going to fare before the Ninth Circuit, apply for a stay!

It seems that if the Golden Gate Restaurant Association intends on winning, it will have to convince the en banc court to decide this case, or the U.S. Supreme Court. In the meantime, the SF Health Care Security Ordinance is going to go into effect. That means we have to read and digest what it requires... which I will do in the future.

DGV

FMLA Amendments Vetoed

Proposed amendments to the FMLA, discussed here, intended to expand the law to cover leave to care for members of the military, are on hold. The President vetoed the proposed legislation, which included a bundle of unrelated measures. The FMLA amendments may pass as part of a new bill. Stay tuned.

“Build It Quick” but “Make It Last” – Lessons in Software Development for Startups

I’ve often been asked what methodology and architecture works best for software development in startups. The truth of the matter is that no one methodology or architecture works best in startups – and that goes for everything from Xtreme programming to SOA to Factory design patterns. I’ve been involved with enough startups to know that you have to take a ‘zen-like’ approach – doing whatever seems right at the time, but all the while keeping an eye on where you want to go.

Given the fast pace of most startups, we don’t have the luxury of strictly following all the rules of any given methodology. I call it a luxury because every methodology has inherent built in processes and limitations - and most methodologies were built to get more reliable software for big projects – not necessarily to get a version 1.0 out the door so that the concept can be proven with customers.

Nevertheless there are some “observations” about development in startups that are worth keeping in mind. I say “keeping in mind” rather than slavishly following some set of rules because the situation might require something else, so keep an open mind. Venture funded startups tend to have more methodology and processes than bootstrapped or angel financed ventures –and for good reason – they can afford it.

So, that said, here are some of my own observations:

• Startups are used to getting sites/products built without big teams. Startups usually have very few resources in the beginning – one or two developers write the entire site. There are usually no QA resources or dedicated product managers in the beginning. This means that:
  
  
  
  • Startup developers have to be more then “just developers”. They have to test their own code and make sure it works– As an example, many Facebook applications are built entirely by one developer in a short period of time without any QA resources (though they are needed as the app gets more complicated). When we started CambridgeDocs, my co-founder and I built the entire product without much QA – we used our initial beta customers to do QA. This doesn’t always mean using JUnit or even always using automated testing, though these can be quite helpful and I recommend using them. It does mean you have to have a set of “smoke tests” that you test out each time you check in your code.
    
  
  
  • Those building the first product need to think of themselves as users of the first product – and not just as “only developers”. This helps to guide the various minute decisions that need to be made rather than always expecting a group of “users” to tell them what to do or an “architect” to make the decisions for them. It also helps with the expanded QA role developers in early stage startups are forced to take on. And sometimes, believe it or not, you just have to play with the “whole” site or product and see if you can break it – not just the modules you’ve written - just like an end user tester would.
    
  
  
  • Developers need to be able to juggle multiple tasks and languages. In a startup it doesn’t work so well to say “I’m only a PHP guy I don’t do javascript or AJAX or action script” – if the application requires both you will need to do both. This means learning enough about different languages so that you can juggle them as needed. For example at CambridgeDocs we decided to do our core platform in java, but we had modules that ended up being built in all kinds of other languages - VB .NET, C, C++, C#, VBA, XSLT. That doesn’t mean that we were able to send people to courses on any of these languages – the developer had to pick up a book or do searches on-line and figure out how much of these languages they needed to know for the task at hand. Usually only a small amount of knowledge of a particular language was required in order to complete the task. In another startup the main platform was built in java, but we were able to build some perl code that did what needed to be done and the first few production clients used this perl code while we waited for the java platform to get done. This was better for the startup than telling clients to wait until it’s done.
    
  
  
  • Developers have a lot of leeway in the beginning. This leeway can be good or bad, depending on your disposition. Usually it means you not just have to do a development task, but have to figure out the best/most efficient way to get it done – use open source/third party tools, do it yourself, use algorithm/architecture # 1 or #2.
    
  • Developers need to give estimates early and refine their estimating. Developers need to give estimates as their “best guess” based on the information at hand. These estimates almost certainly will need to change as the team encounters unexpected difficulties with a particular piece of technology or third party product. Don’t be afraid to give an initial estimate and say “this is my best guess – I’ll refine it as I go” – rather than saying “I need another 2 weeks to study this problem before I can give you an estimate”. Basically you need to transition from a “CYA-perspective” (Cover-Your-Ass) of estimating (which is done in larger organizations) to a “GID-perspective” (“Get-it-Done”).
    



• Startups usually prefer an iterative approach – get something up quickly, then iterate and make it better. This is crucial – what goes into a particular version or product release is debatable almost up until the time of release. In my very first startup (I wrote about this in my book, Zen Entrepreneurship) we were going to a conference in Florida the next day and the product was supposed to be release – we only had one problem – it crashed when multiple instances were running on the same machine. Now we could’ve pushed back the release, but the release date was critical for us, so we got around the bug by simply taking that feature out – it wasn’t critical especially for a first release.
  


• Specifications are usually limited. Most specifications within startups are screenshots or mockups with some explanation. That doesn’t mean that there are no specifications. But it does mean that typically to specify an API you would just go ahead and write the function headers in java or whatever language you’re using. This initial cut would be the spec and then evolve into the final product. Similarly an HTML mockup of a page is the spec for what the page will look like – this HTML is then translated into PHP or java or Ruby On Rails and it morphs into the final product. Usually (fortunately or unfortunately) the initial specs are discarded and the “work in progress” becomes the working spec as the initial version is built. There usually isn't time (again fortunately or unfortunately) for workflow analysis, full UML, etc.
  


• Code needs to be written “cleanly” even (especially) in prototypes. This might seem like a counter-argument to the build it fast argument. But it turns out that in a startup a prototype will almost inevitably end up as part of the production application. As an example, even before we formally started CambridgeDocs I built a prototype of an HTML parser and called it “RizHTMLParser”. I was never planning for it to be a production thing – but as often happens in startups, it was rolled in as the first version of our HTML parser. For years we had a class in our java code that was named after me personally – this happens a lot more than you would think – and our product was being used in production by many Fortune 500 companies!
  
  It’s better to just pick a more descriptive name for the class to begin with, even while prototyping. This doesn’t mean that you should take a lot more time to build prototypes – not at all – what it does mean is that you should take a few extra seconds and write the code cleanly and with names that make sense because it's probably going to end up in production somehow. Same goes for commenting- take a few extra seconds and write some comments. Writing “clean code” shouldn’t take much longer but it helps in maintainability down the road.
  


• Startups need to think about the future, but build for the present. Flexible and scalable architectures are good – startups usually need to follow an architecture that leaves room for the future but that takes into account present needs.
  
  This is a delicate balance between “get it done quickly” and “build it to scale” and "build for re-use" – resulting in something that has some level of “quick and dirty” but done in a modular enough fashion so that it can later be replaced as the codebase is re-factored and the organization gets bigger.
  
  As an example, when we built our first Microsoft Word file reader we needed something quick – we used a bridge from our java server to Microsoft Word and used its built-in API. This solved the problem but was not a good scalable solution (it was single-threaded, and had a host of other problems) – we identified the way we’d like to do it – straight cross-platform java code which read .doc files on the server. But the amount of development required for the eventual solution was well beyond what we could afford – so we did it quick but we isolated it in a way so that it would be very easy to switch to eventual driver when it was ready. This quick and dirty driver actually worked for us for over a year and got us our first few word-related customers, at which point we had identified some clients who would provide the funding for the full development effort. We eventually re-wrote it and the scaleable re-write became one of our key pieces of differentiation.
  
  I like to think of this as a “Build it Quick” but “Make it Last” philosophy. Another entrepreneur I know called I the “version 1.0/ version 3.0” tradeoff –you need to get version 1.0 done, but you want to think about what version 3.0 might look like. It means you need an architecture that doesn’t follow “hard and fast rules” (i.e. this methodology or that methodology) but leaves open the possibility of pieces being written in a less than optimal manner in the beginning in order to demo something to a client and then re-factored over time.