Ask HN: How Should I Discuss Work Expectations with New Employer | Hacker News Reader

Ask HN: How Should I Discuss Work Expectations with New Employer

15 pointssave_ferris8 comments

I started a new backend software development position a little over a month ago with a small startup (just two full-time devs and a few other random code contributors). During the interview process, I explicitly asked about work expectations and got a fairly typical answer (40-45 hrs. per week with a very rare "fire-fight" thrown in).

A month into the job, I notice the ambiguity of that statement more and more. The deadlines I've been given are insanely unrealistic, I've been writing code almost non-stop for almost 10 hours per day over the last week or so, and it's really starting to impact other aspects of my life. We're not really doing any kind of code review or reflection on the work that we do. I'm working on a project that is badly needed to ship, and we're currently not using any software development process around it, agile or otherwise. When I asked if we could implement more structure and discussion around these expectations, I was basically told we don't have time.

I like the company and the people, I find them quite easy to get along with. But I'm concerned about my workload and the seemingly endless pressure to deliver so soon into my time here.

How can I frame a conversation around these concerns in a positive light with my management, without sounding like I'm complaining?

You need to decide what works for you and then make that happen. Hear me out.

Small Startup with 2 devs is never going to be able to create too much structure around things. Forget agile. Client needs a fix. Forget process. We need to ship something now. So that is the nature of the beast.

BUT, you still need to set some boundaries. You can talk to your boss and say "I totally understand that my time is valuable and we don't have a lot of room at this time due to a small team, but I cannot be available after <insert your time> PM."

As an alternative, you could work out a flexible schedule if possible as well. They need you to code 10 hours a day ? Ok, then you will code for 5 hours in the morning, then not be available for a while and then be back in evening from home may be to code a bit more.

Overall, if you like the company and people, try to work it out with them because most small shops have this issue. I run one so I know exactly what you mean.

This is a negotiation process.

1. Decide what you will do if they refuse to change things (the jargon for this is "Best Alternative to Negotiated Agreement"). Personally I would start looking for new job if negotiation failed, but you need to decide for yourself.

2. Figure out why the long hours are happening, i.e. what the management goals and decisions are that are driving long hours.

3. Do some prep research on why long hours are counter-productive (e.g. read http://www.igda.org/?page=crunchsixlessons).

4. Try to come up with alternative plan that will meet management goals while still being sane workweek. E.g. "we need product shipped, but features A and B are essential, X and Y are nice-to-have. Let's do A and B, ship, see what market says and then think about X and Y."

5. Go talk to them about it, presenting arguments why current way of doing things is bad for their goals ("long hours reduce output") and your plan is good for their goals (e.g. "we can ship product on time, with the features that really matter").

(See also https://codewithoutrules.com/2016/08/18/productive-programme... and https://codewithoutrules.com/2016/08/25/the-01x-programmer/.)

This sounds like a typical scenario

- software developer position in 2017 = Micro-managed and treated like resource

- no creativity, just productivity

- small startup where you own %0.1 of the company while the CEO and CTO get %99.9

It's hard to change something that look fairly reasonable. I'd simply look for a larger organization that offers a much better work/life balance if this is what you really want.

> When I asked if we could implement more structure and discussion around these expectations, I was basically told we don't have time.

There is a subtle art to managing-up, that is managing the boss. Start the conversation by asking him how he thinks things are going. Share your concern that the team may not be using it's time effectively. Pitch the idea again to try Agile Methods as an experiment to work more efficiently. He may have limited experience or poor exposure to working in true Agile environments.

This HBR piece on Embracing Agile is a solid suggested read > https://hbr.org/2016/05/embracing-agile

Finally, start making 6pm your COB time, just close-up. Say "Gotta run, have a good night!" And Go!

Just going home at a certain hour is a good approach, but it still leaves the problem of impossible deadlines. So it's a good thing to combine with some level of explaining to management "this isn't going to work."

Reality is: these guys are early stage, and they need to do whatever it takes to ship and find their feet. They cannot afford to work less as a team - it will not slow down.

So, 2 options:

IF you believe in the team and the market and are convinced that this is worth slogging for 2-3 years, then negotiate a better equity deal. Tell them you want all in and are willing to work your ass off, but you need more upside than just an "engineer cut". If the company hasn't raised money yet you're equivalent to a founder. Make a deal.

IF not, i.e if you don't believe in them 100% or are not in a position to work your ass off, then quit. Find a job that offers good salary and work life balance. A growth stage startup, or a large company if you're up for it...

Hope this helps.

1. For a small start-up, this seems to be the norm. I'd be very surprised to find a company if that size with "normal" working hours, unless perhaps they're already profitable and have a secure market lead.

2. You don't actually need a lot of progress when you only have a couple of devs. Process is a compensation mechanism to deal with the complexity of large teams and / or mature products. A really great product leader on a v1 product can effectively run things with nothing more than a burndown list.

3. Depending on where you are in your career, this may be normal. It generally takes newer devs a longer amount of time to get ramped up when starting something new.

I've worked for two startups where I was able to negotiate <40 hour workweeks. Definitely much harder to find, but there are some small companies that understand that working long hours doesn't increase output.

Reply on news.ycombinator.com