Hacker News new | ask | show | jobs
by cgore 3110 days ago
"we expect people to act like an owner"

This has got to be the most stupid thing I've ever heard in an interview. Okay then, I'll act like an owner. Make me an owner. Oh, wait, you didn't mean it like that?

4 comments

In my experience it almost always means "I expect you to work 14 hour days like I do even though I have 40x the equity you do."
40x would be a lot more fair than what I've seen. Usually it's > 100-1000x in a different stock class(preferred/common).
founders have common.
Yeah, and that's exactly my point. Okay, I'll act like an owner. Make me an owner.
How ridiculous! You should just be thankful for the opportunity to be part of their incredible journey! Think of all the exposure and experience you're getting! /s
The sentiment they are trying to get across is that they want someone who won't let problems lie and who will proactively execute on fixes without waiting for permission or being assigned the work by a tech lead or manager.

Couple of examples of this:

1. Speeding up a test suite by identifying the slowest parts and optimizing it so every developer that runs the test suite benefits.

2. Making deploys more stable or getting them to zero down time so you're not forced to deploy during off hours and impact your customers.

Wanting people who will do things like this is often expressed as "ownership", but I think it's the wrong term. It's more about making the team more efficient and productive.

The sentiment they're getting at is "We want people who are as dedicated as owners, but without the incentives" and this translates to "We are only interested in gullible people who don't know their own value."

The reason people have trouble finding good developers is because they don't want to pay for them. Owners aren't driven by only doing as well as the market average. If you want people who want to beat the market, offer them something better than the market rate.

> The sentiment they are trying to get across is that they want someone who won't let problems lie and who will proactively execute on fixes without waiting for permission or being assigned the work by a tech lead or manager.

I find that's rarely what they want. I've often seen cases where there's some fundamental architectural flaw that will make future development extremely difficult, only to be told, "Don't worry about these things - just ship something!"

Yeah, that's going to break really soon, and we'll be running around trying to put out fires because of your incompetence. If I were the owner of this, I'd fix it immediately, or at least prioritize it reasonably so we don't screw ourselves in the future.

I think that's called being diligent or conscientious. Or call it "doing a good job" or "being a professional".
> The sentiment they are trying to get across is that they want someone who won't let problems lie and who will proactively execute on fixes without waiting for permission or being assigned the work by a tech lead or manager.

And I assume they schedule time for such activities? Or do they expect you to do it on your own time? Or do they expect you to do that in addition to what you're already being paid for? Will they reward you for your effort or will you just kick off a round of bullshit on why you made an unnecessary and un-requested for change?

Everyone wants their devs to take ownership, but very few create the right business structure to make it possible.

> Everyone wants their devs to take ownership, but very few create the right business structure to make it possible.

Totally agree on this point. In most companies, this work is not glorified and ends up being done on "stolen time" from the employee, or not done at all. It's a sad state of the industry.

I'd say this is where the more engineering-focused companies tend to excel a bit more since they are more likely to schedule the time and reward folks for doing it.

If you're evaluating companies for fit, its a good idea to ask questions around how this work gets done (asking for specific examples) to see if you glean if it's valued or not.

It can mean different things, no? For example, a team was switching to git from a different vcs. Devs who actually gave a crap then researched best practices and wrote up an internal how-to for everyone else to follow. Not because they were "business owners" or told by the management, but just because they knew there would be total chaos if they didn't. Other people - who somewhat cared - followed the internal manual. Finally, people who should be fired started shitting right into master without reading anything on git, internal or otherwise. In my mind, the first set of devs really acted like owners here. Nobody exploited them, or even pushed them to overwork, they just knew to do the right thing.
Yeah, they're not "business owners", they're just fake owners who will be fired when writing the internal how-to took too much of their work time.
Yeah, it's like, act like an owner, but you have to do everything that the _actual_ owner tells you to.