4 ms·

Here's my approach: "Look, there's two ways I can respond to this. I can be honest with you, and tell you the truth about how long I think it's going to take.

Here's my approach: "Look, there's two ways I can respond to this. I can be honest with you, and tell you the truth about how long I think it's going to take. You might not like the answer, but at least you will be in a position to make properly informed decisions about what to do, such as reducing the scope or adjusting the launch date. Alternatively, I can lie to you and give you an answer that will make you feel satisfied when you leave the meeting, but is inevitably going to cause trouble for both of us a few weeks/months from now when the expected deadline is missed. Tell me which kind of response you'd prefer, and we can proceed from there."

ornornor 5y ago
What do you do if they choose “door number 2”, when the deadline is approaching and you’re pressured to work overtime while delivering subpar code that will be a major pain to modify and maintain for the rest of your time on that project, leading to even more pressure and overtime?
- peterkelly 5y ago
  Quit (yes, seriously). The extreme toll that burnout can take on your mental health simply isn't worth it. There are greener pastures out there and these days I only work with clients that prioritise quality over speed.
  - ornornor 5y ago
    I’m genuinely interested because I’ve miserably failed at it so far. When I inquire about the speed vs quality trade off in interviews or during discovery, the answer is always that quality is paramount. But a little later, when it comes down to the brass tacks, we’re asked to make the trade off and put speed over quality. Every time. Even when it was the company’s motto/yearly objective to “focus on quality”, even there, eventually speed was more important when pressed. So I’m wondering: how do you find out whether quality is just lip service? It seems like a simple answer but over the last ten years I’ve always gotten it wrong and the project ended up being a pressure cooker with overtime to “fix” it.

ornornor 5y ago

What do you do if they choose “door number 2”, when the deadline is approaching and you’re pressured to work overtime while delivering subpar code that will be a major pain to modify and maintain for the rest of your time on that project, leading to even more pressure and overtime?

peterkelly 5y ago
Quit (yes, seriously). The extreme toll that burnout can take on your mental health simply isn't worth it. There are greener pastures out there and these days I only work with clients that prioritise quality over speed.
- ornornor 5y ago
  I’m genuinely interested because I’ve miserably failed at it so far. When I inquire about the speed vs quality trade off in interviews or during discovery, the answer is always that quality is paramount. But a little later, when it comes down to the brass tacks, we’re asked to make the trade off and put speed over quality. Every time. Even when it was the company’s motto/yearly objective to “focus on quality”, even there, eventually speed was more important when pressed. So I’m wondering: how do you find out whether quality is just lip service? It seems like a simple answer but over the last ten years I’ve always gotten it wrong and the project ended up being a pressure cooker with overtime to “fix” it.