04/01/2013 15:28:26

As anybody who has read my resume knows, I used to work at a company called Benefitfocus. At some point I decided to move on. Now if you spend some time looking at Benefitfocus' website you will probably come away quizzically as according to the culture page there, I would be a great fit as an employee. Sadly, nothing could be further from the truth. Don't get me wrong. Working at BF was a great experience. One that I would not hesitate to do over again if I had a time machine. However this was primarily because of the people I worked in close proximity with, not the company we worked for. Of course the company has to receive some credit for that. Somehow they managed to attract all of this talent. On the flip side, keeping the talent there is becoming a more prominent issue with each passing month and year. It is an issue that BF seems reluctant to take on.

But what is the problem? Why did I leave? Why have others left? Well I cannot speak for them so I will fallback to doing the one thing I excel at above all other things: Speaking for myself. To put it bluntly, I left because the software we were releasing was generally crap and the software we didn't release was generally good. Go back and read that sentence again. That's right. They got it backwards. I never worked harder at any job (and yes that includes my current stint as an independent developer) than I did at Benefitfocus. The hours were long and the challenges were immense. But we had teams that could take it all on and come away in one piece. I acquired a massive amount of knowledge within my 13 months of working there. Even now I still miss working there on some level. And yet... leaving was worth it. Because now even just two months into my stint as an independent developer, I've accomplished more than I could've ever hoped to in a decade at BF.

For me the end is just as important as means. Not more important or less important but just as important. You can't cut corners and expect to come out on top. Just as you can't dilly dally around forever and expect to produce anything that's worth a damn. Sadly BF is the king when it comes to cutting corners and the products they deliver to their clients suffer as a result. For example, over the last few years, BF has managed to hollow out their internal QA teams by refusing to replace staff members that either quit or transferred to different departments. You can't produce great software without great QA. Somebody's got to dogfood this stuff and if you are turning your paying customers into guinea pigs, it will only be a matter of time before they cut loose of you. Nobody wants to pay for the privilege of eating shit.

BF also suffers from constant internal bickering regarding what technology platform to build their products on. They started off writing software in Java, then dipped their feet into the .NET pool and eventually waded into the Python side of things. While I agree that a heterogeneous approach is the superior approach, the way in which this was handled at BF was brutal and vindictive. Simply put: Various teams working on various platforms have at one time or another suffered under the yoke of fear that one of the other platforms was going to displace them. While working on the .NET side of things I recall several incidents in which we heard rumors that all of our software would be replaced by Java equivalents. Hell the original .NET application platform developed at BF was developed with the sole intention of replacing the Java platform currently out there. Now that didn't happen, but I know what it feels like to be one of those Java developers who spent a large portion of their existence believing that it might happen.

Don't get me wrong though, it's not all bad. The world is tough and having a bit of a dog eat dog approach is probably a good thing. However this wasn't dog eat dog so much as it was two dogs with their nutsacks tied together being thrown into a cage while sickos looked on in hopes that one would tear the other apart. Technology decisions were neither made based on the merits of the technology nor were they made based upon the potential windfalls the technology could produce for end users. Instead they were made based upon the end results of political pissing matches that, from the perspective of employees like myself, made little more sense than deciding the future by throwing colored sand in the air and assigning value to the random pattern of the resulting mess. The reality of this is what drives developers away.

As if the leadership deficit at BF wasn't bad enough, you've also got the offshoring factor to contend with. If you surveyed every developer at BF who had worked hand in hand with the offshore teams you would receive a unanimous response: They are terrible. That's not to say that they aren't nice people. But at the end of the day - I spent more of my time at BF cleaning up the messes made by the offshore team than I did creating great software. During my exit interview I made a point of telling the HR Manager that should BF simply fire the offshore team (henceforth referred to as OSO though keep in mind they are contractors working for Value Labs out of India) and that they wouldn't need to hire any onshore heads to replace them. The HR Manager was confused and asked me, "But who would do the work?" I replied, "We spend more of our time cleaning up their messes than it would take for us to just write the software ourselves. They have a negative effect on productivity so there is no need to replace them." Of course the reality of this situation is detrimental when it comes to the quality of the software that BF puts out. I have literally worked a 60+ hour week directly prior to a release feverishly hacking up code that OSO spent three months working on which, despite their claims of being on schedule and ready for release, didn't work at all. And by didn't work at all I mean that hitting any button within the module would result in an unexpected exception being thrown. Our hacks were enough to just make it work. We never fixed the core issues in the software. That code is still in production even today despite the fact that I begged management for the chance to rewrite it. Keep in mind that the OSO teams at BF have their own QA personnel. Clearly they aren't doing that great of a job.

So the natural question is: How is this situation allowed to continue? Why has the executive team turned a blind eye to this? Well when it comes to the executive team at BF, you need to understand something. Namely you need to understand that with a single exception, the entire executive team is composed of people who are clueless when it comes to technology. On top of that, these are the kinds of people who surround themselves with yes men and yes women in an attempt to bolster what is clearly a flailing sense of self worth. Combine that with the dog eat dog politics at BF and you've got a bubble in which reality, no matter how detrimental to their future, is not allowed to percolate. Take for instance my last two weeks at BF. Within those two weeks I attempted to schedule a meeting with the CEO of BF, Shawn Jenkins. He has consistently claimed to foster an open door policy. Given that I thought sitting down with him for half an hour and discussing my experience at BF would be beneficial to both of us. After a week I discovered that he had stealth declined my meeting (i.e. cut loose without sending a notification). So I called his secretary, who refused to call me back. I then rescheduled the meeting for one of my last days there (while checking his calendar to make sure he was available mind you) and left a message with his secretary asking for confirmation of his attendance. I finally received a phone call from her just a couple of hours before the meeting during which she explained that he would be unable to attend due to a client meeting. Make no mistake though, while the Engineering teams were prepping for a release that very afternoon (myself included), Shawn was actually participating in a kegger with the sales/support staff on the other side of campus. Keep in mind that this is an individual who has a cubicle in the engineering area of BF. He claims to live and breathe software development. Yet in the span of an entire week spent in Charleston in the engineering area, I did not catch a single glimpse of the man nor could I find any way to open the door to his office.

It seems clear that he did not want to meet with me. Perhaps my reputation for being outspoken had gotten around. I cannot say. What I can tell you is this: The executive team at BF exists within a bubble. Within that bubble things like the Facebook and GroupOn (a BF client mind you) IPOs were great ideas. Within that bubble they recently came to the conclusion that the best way to prepare for their IPO this year was to add three more teams of offshore developers. Within that bubble they think it's okay to announce the availability of products for which not even a single line of code has been written yet (point of reference: Shawn Jenkin's claim in 2012 Q2 that BF's Healthcare Marketplace software would be ready in 2012 Q4). Lots of employees were stunned by that claim. Especially since the software he demoed during his One Place 2012 keynote was nothing more than a front end demo put together by the UXG team (note: Most BF software demos are just that - smoke and mirrors).

In addition to all of this, BF's relationship with the press and the public is dysfunctional at best. Take for example this article from December 2012 which covers the grand opening ceremony for their second building on the BF campus in Charleston. It sounds great, right? Wrong. For starters BF has been working out of this building since 2010 at which time they occupied just the second floor of it. Secondly the article makes absolutely no mention of the countless hours of productivity that were lost as developer's on the second floor had to listen to the sounds of construction taking place on the floor above them. BF management was entirely too cheap to pay for the construction to take place at night, despite their claims of fostering a wonderful work environment for software engineers. Thirdly, the 300 new jobs they refer to are largely offshore jobs. Since most of the offshore personnel are cycled to live and work in the states for several weeks/months at a time, they apparently have no qualms about claiming that those new jobs will be in Charleston. It is a blatant lie to say the least

So take my advice: When it comes to the Benefitfocus IPO, let the suckers buy in first. That having been said, there may be an opportunity to buy low and sell mediocre here, but never ever make the mistake of believing the BF hype machine. Get out quick.