Hacker News Reader

Comment by tyre | Hacker News Reader

I used to work at Gusto (ZenPayroll back in my day) and dealing with Zenefits was always a pain for this reason.

They were the consummate hackers, using screen scraping and automation to do whatever the hell they wanted. One nightmare example was when a bug in their "automated" system rewrote bank account information for tons of employees to just be the last 4 digits of their account number. Such a mess.

Even if this weren't a tightly regulated industry, you're dealing with how people are paid and covered for health conditions.

We didn't hire hackers[1] because that attitude just doesn't fit for certain classes of problems.

Hats off to the investigative journalism by BuzzFeed, uncovering some frightening immaturity pervasive in Valley companies.

[1] I authored this post about our hiring at the time: https://gusto.com/blog/zenpayroll-is-not-hiring-hackers/

View on HN

That blog post is one of the best advertisements I've ever seen for a tech company. If I weren't happy where I am, I'd apply for a position immediately.

I get that moving fast and breaking things works for some products, but I wish more companies had the same attitude as you.

Glad you liked it! I'm now building software for local government and we've naturally taken that ethos to our new company.

If you are ever looking for another opportunity, check us out http://seneca.systems

You had me at "...building amazing technology to unf* government."

I'm not looking at the moment, and not in SF, but having a minimum vacation policy and working on software for governments is impressive to me. Kudos.

CRM for government reminds me of the Ted Talk where a guy said the government should use source control. We're not there yet but it's a step in the right direction.

You guys should seriously consider using resellers and distributors btw. Gov't purchasing agents always request three competitive bids.

That's true if you try to sell into the municipalities via the RFP process. However, we sell directly to the departments who will be using our software. We've met with great success doing it this way.

In fact, we managed to close a department in Miami in only six days--that's basically unheard of in local government software sales.

You're right that is fast. Keep up the great work!

Your values page is interesting, though the quotes may be a bit excessive. If you don't mind my drive-by critique, I would suggest listing those quotes at the end of each one as a kind of an "alternate telling."

For the "empathy" value:

> Oftentimes, this means acknowledging weaknesses and having difficult conversations. Feedback should come from a place of love and respect, under the assumption that everyone has acted with the best of intentions.

May I ask how this differs from the management consulting practice called "front-stabbing"?

And for the "Don't Always Be Right":

> We recognize that experimentation is crucial to innovation. We will not accepts “it works” as good enough.

Being right may be orthogonal to taking risks + building a legendary product. Perhaps a better wording would be "Don't settle for just right"

This is great feedback: constructive and substantive.

I like your idea framing the quotes as an alternate telling. They were listed first out of habit (ex-philosophy major), but you're right that this is primarily our story to tell.

Empathy

The difference between front-stabbing and giving good feedback is one of maturity. If you've had many conversations with young kids, they are incredible at giving blunt feedback, but it's only funny because they are tiny humans. Some of what they say would be unconstructive coming from an adult.

Front-stabbing, to me, is someone trying to justify being an asshole. Your comment is a great example of the difference, of being honest and direct but mature. The opposite of the kumbaya culture isn't telling someone they suck, even if you do it because you want them to be better.

Don't always be right

This is my fault, I mixed too many concepts. This value is about not getting complacent with success or being afraid of failure. I don't want us to get it right every time, because experimentation (where the magic happens) involves making mistakes. As you point out, that failure isn't the same as taking the right risks. This value is counteracting our need to be perfect, about pushing back if we seem to always be getting what we expected.

Happy to dive deeper if I didn't answer your questions. Thank you for the thoughtful consideration!

Thank you in return for thinking through my suggestion :-)

Everything you said sounds fine, with the exception of what makes front-stabbing, front-stabbing.

I agree that maturity is important for giving constructive feedback; just as important, in my opinion, is closeness. That closeness is certainly achievable in a small startup, but the company scales, I have strong doubts that it will match the level of honesty Empathy, the company value, demands.

More to the point: when unleashed in a social context where all parties aren't friends, I believe that "true" honesty (concerning a person's work) will inevitably transform into front-stabbing (attacking a person via their work) .

If someone who I was not close with was uncomfortably honest to me in the middle of a meeting, in front of many other people, I would probably ask myself "Is this person saying this because I'm actually doing something wrong? Or is he just trying to make me look bad?"[1]

When many ears are listening and many eyes are watching, I know I would feel less inclined to reflect on her or his words, and more inclined to worry about my loss of face. Especially if this person has made a habit out of being vocally honest with others. In my opinion, maturity isn't 1:1 with morality; a person can act like an adult and also be ruthlessly ambitious enough to take advantage of and hurt others.

The deep, deep end of being uncomfortably honest among others in a workplace is a struggle session, where one person is in the middle of the room being berated by everyone else. No one wants to let it go that far, at least not initially, but I certainly believe the basic social lubricant of politeness must be valued, and applied in most contexts[2]

Privacy, maturity and closeness are the makings of a real heart to heart, where both sides can learn from each other. Missing one, or having any in deficiency and, as the company scales, the risk of front-stabbing grows exponential[3]. Said another way by a Wall Street Journal commenter: "You better not front-stab your boss."

[1] There was an article recently that surmised that all public apologies are purely P.R; any demonstration of heartfelt guilt is quickly exploited as an act of weakness, so the apologizer is as tightlipped as she or he can be. Can't seem to find it...

[2] Of course, the other deep, deep end is a Japanese firm where the knives are under the table instead of on the plates!

[3] It's 1:40a.m. in NYC so I hope I'm coming across as explaining my perspective instead of as some kind of internet troll.

I understand more where you're coming from and I absolutely agree. Part of it is my vocabulary, specifically co-opting the word feedback.

In public situations, like giving a presentation or a meeting with multiple parties, a huge part of empathy is understanding people's sensitivity to being ganged up on or feeling embarrassed in front of other. Politeness, specifically around being less brutally honest in group settings, is meant to deter this.

Feedback, to me, is a 1-on-1 activity. Much closer to a heart-to-heart, which requires both the confidence to stand by your values and the vulnerability to be open to change.

Ah; I now understand your position better, and see that it is not too different from my own. I feel like what you wrote here would work perfectly as another paragraph in the Empathy section.

I'll be keeping tabs on Seneca Systems regardless; best of luck to you, Mr Founder!

I love this conversation, and I'd like to give my feedback. First, no, you are coming across as a person who thought deeply about this concepts.

I like the idea of closeness but, as you noted, it is not always possible. I think that empathy is the right word, but should be better characterized. Empathy is trying to establish a connection, is to bring the two people close when giving the honest feedback so that it is perceived correctly. How to do it, that's another story.

One technique that I found very powerful is called feedforward. The idea is, instead of saying what someone has done wrong, suggest a way he could make it right the next time. Example, you sent an email without the attachment. I could tell you: "you should be more careful!" or I could give you a constructive idea, maybe creating a connection: "I understand that sometimes it happens to forget an attachment. I developed the habit of putting the attachments in the email before writing it, so I don't forget them". It is not a perfect example. But even if we aren't close, it gives you a sense of closeness, a feeling that I understand you, and I care about you.

The problem with this approach is that the receiving party should be receptive. I used this method and I received answers like "But I believe I was right because...". And this is the end. You could ignore the answer, knowing that your feedback was useless, or you could try to explain, but you have lost. Nevertheless, if the feedforward is ingrained in the company culture, it is something known and actively practiced (that means the example starts from the CEO), it helps to create a positive environment.

I'm not sure if that's what he means by empathy, or maybe his company uses a different technique. You are right: closeness, privacy, and maturity are essential for a positive culture were front-stabbing (or worse, backstabbing) is impossible. And empathy is the ability to bring someone close, especially when it is relevant to provide important feedbacks.

Excellent response, thank you for your thoughts.

I like the idea of empathy being a bridge between two sides-- closeness helps in building that bridge. If the sides are way too distant, the bridge will inevitably collapse into the abyss. But if the bridge itself is made of strong stuff, constructed in good faith, then absolute closeness isn't so big deal. So long as trade of ideas can safely go back and forth across that bridge, in equal measure. I might be stretching a metaphor a bit there.

Feedforward is indeed quite powerful between two receptive parties; the last time I got a peer review the person I was doing with did it to me, which made me all the respectful of him.

"empathy is the ability to bring someone close" indeed!

Ironically, Facebook which popularized the saying "move fast and break things" is actually more reliable now than many slower-moving systems.

http://mashable.com/2014/04/30/facebooks-new-mantra-move-fas...

It's a question of the cost of a bug.

Frankly, bugs with Facebook were trivial for the first few years.

Payroll, insurance those bugs cause serious problems that create substantial financial costs for your customers and possibly regulatory fines.

Without knowing much about the situation... how much was this necessary? The industries Zenefits are working with aren't exactly tech-friendly, and I just always assumed Zenefits was doing some gross things on the backend in order to make things easier for the user.

(This doesn't excuse bad testing or bad code, but it's not like the insurance industry has well-documented public APIs for Zenefits to use)

ZenPayroll has an extensive API (I built it.) They did it because they wanted to.

http://docs.zenpayroll.com/

Reminds me of mint.com. I used to work at Venmo and they tried to integrate with us, but then without even reaching out to us they decided they couldn't because of the 2fa on our web login. We had a documented developer API but they seemed to never even consider using it.

> uncovering some frightening immaturity pervasive in Valley companies.

This is one of the dark sides to having an entire engineering team in the 25-30 age range. They can sling http just fine, but sometimes don't fully grasp the consequences of their work.

I was 22 when I started and cared very deeply about the consequences of what I was doing.

It's more about heavily interviewing for alignment with your mission. If people care deeply about the problem you're solving — not just the technical problem, the people problem — then you're far less likely to have these issues.

I interviewed dozens if not hundreds of people at ZP and there were two red flags for engineers:

1) They only care about the technical problems. In this case, they're likely to make decisions more aligned with "that's interesting" than "that helps our customers"

2) Once we raised our Series A, we had a lot of applicants wanting to join a rocket ship. I literally heard that in an interview with a Facebook engineer who found us by "googling startups with 9 figure valuations." If you care about growth at all costs, you're going to cut corners and fuck over your customer.

Mission matters. Values matter. Interview for them.

Thanks for that tidbit. I work for a non-profit and sometimes it's hard to make the call when someone is technically sound but doesn't seem to get the mission. So far we've managed to get mission oriented people on board, but I'll make more of a conscious effort in the future.

This is the essence of why Zenefits is in trouble. One of the mantras Parker would frequently state around the office was something very close to "growth is responsible for all of our problems and also the solution to all our problems".

His view, if I'm recalling correctly, was that hypergrowth makes customer problems more visible due to scale while making the company inherently more valuable. There was absolutely no downside to growing as fast as your imagination could manage - despite an accumulation of red flags, technical debt, and unhappy employees.

As you mentioned in your comment, values absolutely matter. I think Sacks gets this, but a company this deep in with so many employees is a big, unwieldy ship that's hard to turn.

> There was absolutely no downside to growing as fast as your imagination could manage - despite an accumulation of red flags, technical debt, and unhappy employees.

I worked at LivingSocial early in my career and this is so true. There is a limit to how quickly organizations can grow (given our current understanding) and still be healthy.

Employee happiness and related metrics (e.g. retention) is the biggest indicator of health. I don't care that you hired 400 people this year. Can you retain 40 world-class people?

Didn't mean to imply it was impossible to care/have awareness to care at a young age, just that it is rare.

I know what you mean, and most of the people I hire end up skewing older. For engineers, experience usually tames the "ooh let's try this shiny thing!" because they have had experience trying to maintain that beta JS framework or been paged at 3am to deal with their hacked together nightmare.

It is absolutely more rare to find younger people who are already aligned with that mentality. That's not good or bad, just a matter of fit.

At 12 I was a hacker. At 22 I was very serious + responsible. At 35 I've learnt when I should act like a 12 year old.

So hacking is reserved for research project and the odd on-off script which gets nowhere further than my PC ;)

I've had hackers in my team, they've always been strong technically (they take risks so learn fast) but they have always been a net negative in the long run if left uncontrolled. But put them into the right environment and they can be very effective (as they tend to be very creative).

The question is will an ex-Facebook hacker accept being kept at arms-length production and treated like a junior developer? It works for me because there aren't any AAA employers here in The Netherlands.

While there may or may not be a darker side to having an entire engineering team in the 25-30 age range, according to the reporter that wrote the article, this hacking came straight from the CEO, who also set the tone for this type of behavior:

https://twitter.com/williamalden/status/697898496314077185

<<I’m told that Conrad created this program based on a belief that 52 hours was too long to spend in training>>

I realize it's the law, but that is an interesting question. I'm a page-at-a-glance reader (not to brag) and sitting in front of something for 52 hours would make me feel like a character from "Harrison Bergeron".

The 52 hours is meant to be spent exploring inside of an LMS (Learning Management System). You aren't simply reading a manual, but rather going through lessons, taking quizzes on them, working through different scenarios, etc. It's supposed to be an interactive process where you're familiarizing yourself with the information, learning to identify how to handle different situations, learning what "gotchas" to watch out for, and generally reinforcing your recall of the rules and regulations around the industry.

The LMS has the actual license exam locked until you've clocked 52 hours inside of it, so the macro just ran out that timer until the broker could get directly to the exam. Scraping by an 80% on that license exam (especially with all of your colleagues around that have taken it already) is ridiculously easy.

Insurance companies are sticklers for technicalities and love to deny claims, so as a consumer I'd consider the 52 hours / 6.5 work days worth of required training to be an absolute necessity for an insurance broker.

Disclaimer: My current company got our insurance royally screwed up in the short period of time we used Zenefits thanks to their corner cutting, so I'm a bit jaded.

Thanks for explaining that further!

So then they should make the licensing exam harder. People learn at different rates, they shouldn't punish fast learners.

I started my career working on software where serious bugs could get people killed. You do need experienced mentors, but they certainly could be under thirty.

You don't have to be old to build things safely. You just have to care.

...and have time, and funding, and patience. 2 out of those 3 are in short supply in Silicon Valley. Robust software is eminently possible, but it requires a development culture that is often incompatible with shipping lots of things quickly and seeing what sticks.

I recall that when Parker Conrad spoke at the Stanford startup class, he said that he'd been turned down by many VCs, at least one of which said "Well, if you were Twitter, this would be a different conversation." His take-away from that is "Well then, what can I do to become Twitter?" Only problem is that health insurance and 140-character text messages are wildly different industries.

As an aside this is something people absolutely do not get. MongoDB haters were always quick to point out how the database can lose data; even after the journal was introduced and that became much harder. But MongoDB failed to explain this same thing well: if you are storing payroll information you need a very robust data storage solution. There's a cost to robustness, however, which you probably don't need to pay when storing 140 character messages. Write concern is a very fundamental business decision.

In other words, when I picked MongoDB to store NowPublic SCAN data, before the word NoSQL was in vogue, even, then it was scanning various streams (including the Twitter gardenhose so many years ago) for bits of news and the ability to store lots and lots of small bits of text quick as hell was much more important than keeping all of them. Noone really cared about every single one, we were in the business of surfacing breaking news and we were a very small startup so not needing lots of expensive servers were a huge plus.

Obviously I picked a very different data storage model when I needed to store payment data at a TV station's video store...

Absolutely.

We used Facebook as an example all the time. For them, moving fast and breaking things is a good value. If someone's status update got lost, that isn't ideal, but it isn't the end of the world.

When people don't get paid, that's a Big F-ing Deal.

It's an easy trap to fall into as an engineer. There are many cool problems to solve, but when you join a team you're agreeing to solve their problems. Focus on the customer.

The guy on my team who's a 'hacker' is in his mid 30s. Some people just never grow up. I'm 27, and I'm the guy always arguing with my near-40 boss about trying to do things the right way, not the way that's easiest today. Age is probably the generalization to make, but cargo-cult mentality isn't in any way limited to then young.

Does his code work?

This is a very low bar for success. When you're working with sensitive information or financial transactions, it isn't just about "working". If your code "works" but is impossible to reason about or untested, you're asking for people later on to introduce bugs.

Code is not written in a vacuum. The hardest part, for three nines of software problems, is not just getting it to work. It's architecture and building an engineering team that functions together. People are a major component of software development.

Not sure what your point is, but thanks for the condescending digression.

I bailed mentally at an interview with a YC startup in SF because, as part of the technical portion, they had me write a scraper to pull information from searches on other sites. This was against each site's legal/usage terms (and so was defeating the basic obstacles the companies put in the way of being scraped in bulk). When I asked about their business model they revealed that they were making money by doing exactly this and had zero intention of changing that or partnering with the other sites to legally obtain the data.

Their recent series A made them so cavalier; they landed money to do this, so of course it was right. It would eat into profits if they negotiated contracts to do it aboveboard.

Priceonomics?

No answer means yes.

Actually no, that guess was incorrect. I just didn't check for replies until now.

I'm not sure how age-related this is.

The Valley has started to equate "disruption" with breaking the law. This is its natural consequence.

I wish it was just the 20 something programmer that did this. I know more than a few 40 somethings that never evolved out of the good enough phase of development. They can't even be bothered to test their own code before hitting submit. Everything is just a small bug that can be easily fixed later.

I am not sure 25-30 year old engineers are the problem. The problem is management and leadership

Issue you are talking here seems to be about pushing software with a critical bug (a logical mistake by the developer). This issue looks to me as a test scenario that wasn't covered before. I guess these kind of issue could happen at anywhere else too, irrespective of their working (hacking) culture.

My problem isn't the bug. Bugs happen. It's that a developer thought that screen scraping a payroll system and setting up a recurring job to overwrite all bank account information in the middle of the night was a good idea.

If you care about security and stability, that should have set off major alarms.

Scraping data and pushing to internal APIs in another product have no spec, so any tests you write are either wrong or not wrong yet.

Reply on news.ycombinator.com