Latch Bio: “We work six days a week”
jobs.lever.co
jobs.lever.co
It just seems like it will be amateur hour: immature founders who are in love with startup culture combined with junior and/or desperate employees who don't know better.
I don't mind working hard, crunch, or even acting like an owner but when the these listings also have average salary ($135k - $190k [0]) with no mention of equity (meaning it's either 0.00% or not substantial), that's not ownership; that's a bad deal. If you want me to act like an owner, I expect to be treated and compensated like an owner or at least more than a "cog role" at another startup would be.
Any founder who does the math on what it would take to hire a senior+ employee to behave like an owner (a very large chunk of your employee pool) will realize it's not feasible to hire like that.
[0]: https://wellfound.com/jobs/2524214-systems-software-engineer
Easier to buy a lottery ticket.
I saw this in a job posting recently:
No mercenaries! We want people who have been waiting their whole lives to work on something like this.
They don't explain what a mercenary is but from the context it seems they mean people who want to exchange their work for money.It's obviously important for people to enjoy their jobs and be engaged, but anything that reads to me like they want to skimp out on proper pay and working conditions because of how passionate the employees are just smacks of immaturity.
I'm a merc at heart. Fuck you, pay me.
Personally I've had great luck with mercenaries.
As a business owner today, I definitely want a mercenary. A well prepared and thorough mercenary.
The only business I’m willing to be an “owner” of these days is my own. I’ve worked for my dream employer and “took ownership” and learned a few good lessons about how when you don’t own your dream job, it can (but won’t always) become a nightmare.
The lack of awareness is stunning.
I earn <$110k with relaxed and flexible working conditions (but still 37 hours a week). I worked for $170k, had to travel, worked 50+ hours, and “felt ownership” without having any. I understand if their comp range corresponds to an extra day’s worth of salary to some.
I just couldn’t get $170k without either doing something smarter or harder. The extra money wasn’t worth never being home or present.
Wtf? Are salaries THAT high in the US?
I should've been more specific with regards to it being average salary for an engineer.
It's not at all a bad salary, it's actually a great salary but because of how many places do pay this well, places shouldn't have sky-high expectations of working six day weeks or constant crunch.
https://www.sfgate.com/local/article/under-100k-low-income-s...
The average developer looking for a remote job can probably expect closer to $110-140k as an individual contributor in a fully remote job outside of major cities. I'd say this is the majority of the volume of job openings.
Of course there's a minority that pay way more, but as mentioned, competition for those positions is extremely high. The only reason to pay $150k+ is if a company is looking to hire people extremely quickly and the company wants to pay at a level that makes it very hard for employees to jump to another job to earn more.
Source: My company hires engineers in the $120-140k range. We often talk to candidates who at first say they want $175k. We tell them we respect that, and to come back to us if anything changes. More often than not, they come back 1-2 months later asking for the job and happily accepting $120-140k. In the current market you really have to be pretty amazing in order to command $150k+ for remote jobs. For in-person jobs in SF or NYC, getting those salaries will be easier but you'll be paying extremely high COL.
I know it's a startup so if that's what they want to do, cool (even if I think it's misguided) but I'd expect everyone would have to have some vested equity ie be an owner and not being forced to grind as an employee.
Provided the employee is appropriately classified as except OR they are hourly and paid appropriate overtime rates, I'd expect they are ok. Maybe their hours don't surpass 40? More likely there's no limit on number of hours worked (I'm unaware of any in my state)
The exception is supposed to be for workers that control their hours and managers who control others. Software engineers are explicit exception. The manager exception was cresting problems for low-salary managers so they added salary limit which are talking about increasing.
So either they have a bunch of mindless grinding work to do that doesn't require autonomous thought, or they're going against accepted practice for working productively. I'd be concerned if I was an investor.
The only kind of work I have done where you could add hours was security guard, since you do almost nothing all day.
I worked 12h shifts, 13 shifts per month, and that is probably in the higher end of what's doable.
Some people got really strange from working at night. So it is probably not very healthy ...
https://www.dol.gov/agencies/whd/fact-sheets/17e-overtime-co...
Imagine working Saturdays so you have time for a all day Scrum ...
From "CEO-Founder": "First team in biotech software that actually knows what they are doing when it comes to biotech software", "Advice to Management: Keep doing what you are doing."
From "Contractor": "Rude and overconfident management who make it really undesirable to work there. If they are not successful it will mainly be because Alfredo and Aidan are mean people with a big ego who drive away good people from considering joining the company."
Hm, almost nothing there sounds like "difficult problems in software" it sounds like very routine IT stuff. Of course a lot depends on scale, but even scale is pretty well commoditized these days except for the few companies that are on the leading edge of providing it.
How many people wake up on a Saturday morning full of excitement to go to the office in Mission Bay to build some web visualization dashboards for B2B? Hmm...
I see this as a good thing to disclose, rather than finding out that overtime is expected after you start the job.
Or maybe someone thinks it's better to be explicit about how they work like crazy. Or they want to be "generous" by giving you Saturdays off once in a while.
I always rolled my eyes when Thanksgiving would be near and we'd get the benefit of an "unplanned" day off again.
It's not. Pushing forward blindly largely builds tech debt either through paths that get abandoned or eschewing documentation & understanding. Most teams would benefit from going slower with many more small probes to figure out how to build the best feature vs throwing tons of big features out.
My opinion on this is that a slow Michaelangelo (eg: every stroke matters) is a better product than a really huge Pollock.
There are times to go fast and take on a little debt vs going slow and getting it right.
It's often hard to know the right time to apply the right strategy. I would like to believe that's what experience gives us.
As mentioned in another comment if you’re not a founder this is a waste of your time.
You’ll be better off and will make significantly more comp at a public company / FAANG if you want to work this hard for someone else.
This philosophy is what founders sell to young engineers to burn them out for peanuts and pizza while the founders get an OK exit if they’re lucky.
This is great, honestly. It's a self-sustaining way of enforcing accountability.
If you have nothing to show or demo after a 2 week sprint, during which you were surely assigned tasks to do, it's clear you haven't actually done anything.
Having just gotten out of a role like this: It's not.
It punishes doing backend / infra, tech debt, planning, or any work that isn't customer-facing (ie: stuff your senior+ engineers typically are expected to do). The demo day audience is largely non-technical people rather than it being a technical demo.
If you spent the sprint, or a large part of it, helping others or laying the groundwork for future projects with a company that treats demos like you've stated, you'll quickly push out anyone who is doing anything but blindly working on product.
I didn't leave / get pushed out because of the above, the cycle and meeting-heavy schedule drove me up the wall frankly.
Additionally, I would argue that, especially if you are a senior+ engineer, not having anything to show after a 2 week sprint is a red flag and sets a poor example for junior engineers. Either you aren't meeting expectations for your role, or something is deeply wrong with how your company operates that prevents you from doing any real useful work day-to-day.
Seniors and especially higher should be expected to be spending some amount of their time on mentorship, helping others, creating/advancing product initiatives by planning or coordinating. If your product managers are flying solo with no input or even having non-technical managers dictate, that's worse than pulling seniors into some planning.
I've never had someone lay this out for me but my experience is there is a large chasm between senior and higher. Bridging that chasm generally doesn't come with increased individual technical output, it comes with utilizing others to advance projects with you.
That isn't to say senior+ can have no technical output all the time but I wouldn't be demo-ing an engineering RFC or new engineering initiatives at a demo day which will be consumed by other teams. Demo days aren't for the engineers or even product team; they already know what they did that week, I can go into version control or listen at standup.
There is a general movement to eschew accountability which is a huge mistake because this concept is critical in continuous improvement.
Although, it's not like the first time I've seen it expressed that senior engineers should outproduce juniors in terms of individual tasks/storypoints, and spend lots of time mentoring and pairing with juniors. Which I think is what you're getting at?
I disagree mightily with that. Those goals are in conflict and emphasizing individual stats is more or less the emperor of all perverse incentives. Instead, I favor the traditional agile/scrum emphasis on team velocity.
I would argue that this is an extraordinary simplification. Infrastructure is abstracted away to the cloud vendor insofar as you don’t (typically) need to worry about power, physical connectivity to the host, logical networking at the layer of (for example) BGP, backup power, and so on.
But you absolutely have to concern yourself with infrastructure management to some extent. Be it backups, CI/CD infrastructure, BCDR management, geographic redundancy, proprietary vendor software that has prerequisites that your cloud provider doesn’t manage, OS patching for VMs, and so on.
Even if a business is 100% on a serverless stack for its service, it will still find itself with infrastructure to manage somewhere.
Some businesses have infrastructure because they need some type of interoperability to failsafe between clouds.
Even if a software business could succeed with no infrastructure of its own and no system administrators, that doesn’t have anything to do with tech debt. Tech debt can and does happen in any stack.
especially if you are a senior+ engineer, not
having anything to show after a 2 week sprint
is a red flag
Is it? Couple of thoughts.One: At agile/scrum shops where I've worked, it's the team who's responsible for completing goals and demoing and shipping. Not individual developers. So an IC having their own stuff to demo would be incongruous. (I believe this is official "Scrum" doctrine, not that I necessarily care because I'm not the biggest fan of Scrum)
Two: A senior engineer can optimize their time for crushing lots of solo work, or mentoring/collaborating with the junior devs. In that light, if a senior developer was racking up rockstar individual stats, I'd want to make sure that junior devs on their team are getting enough time and guidance.
I can think of countless exceptions to the above. Maybe you have a team comprised entirely of senior+ engineers and no juniors and there's no reason to really collaborate, so senior engineers should then of course be delivering.