I knew right away I was going to love it there. That's the way to my heart.
And no I’m not a manager.
There has to be a balance. The company can’t exist without both customers (either internal or external) and employees.
I still feel a bit ashamed when I think about how much time they invested (~160%), but I wasn't forcing them in any way. They knew the total budget from the beginning, and with that in mind, we were setting the scope together. It was their will to deliver the best possible quality which made them work the extra hours.
In the end, everybody was happy as the project was pretty successful.
Nevertheless, my feedback towards their team lead was very positive, and that might have helped them too since they both collected a bunch of negative feedback while working with some of my colleagues.
We finished the week's work more than a day faster than planned.
So if the job requires a very high level of Quality you might start by telling people you want them to do it right and time doesn't matter (it's not precisely correct but pretty clear). If nothing gets ever done at all, you might need to talk again ;-)
1. If you - the manager - set the deadline yourself, the estimate will often be off (unless you're very experienced and could do it yourself; see 3).
2. If you let your engineer set their own deadline, the estimate will often be off (unless they're very experienced; see 3).
3. If you have a very experienced specialist set the deadline, the estimate will often be about right.
4. If you give no deadlines at all ("wake me up when you're done"), directs will pour their soul into it more often than not, and beat the estimate you'd get from 3.
The main argument against 1 and 2 is that having too tight a deadline is very demotivating. What's the point in working against a benchmark you can't possibly meet? (Having too loose a deadline runs into Parkinson's law, but the problem is usually that the estimate is too optimistic.)
Having tried 4 with various teams over the years, I'd suggest it can work wonderfully - but only sometimes. It requires that your team consists a) entirely of professionally minded engineers who b) can see first hand that what they're doing is useful. You're better off sticking with 3 when not.
The thing is, good code rarely looks stellar. It looks like code which you understand without much trouble, and usually there's more than one way to make it that way. If you get caught up into the trap of thinking you have deliver something amazing but don't understand what amazing really looks like, you're in for a lot of wasted resources.
After the aforementioned company I worked for a startup, and man was it a joy to actually ship code that affected lives. Sure, the code wasn't always the most polished, but being trusted to find the right balance between technical debt for speed of execution felt great.
Sometimes saying 'things should be done right no matter how long it takes' just means the management is unable to balance technical debt with other objectives.
1. Everybody who disagrees with my manager's statement are working in software (I was not).
2. In software, nobody can seem to agree on what exactly "quality" means.
Software is still such a young field that nobody can seem to agree on anything at all. It reminds me of other fields 100 years ago, where you could just try anything and if it seemed to work that was fine.
> Sometimes saying 'things should be done right no matter how long it takes' just means the management is unable to balance technical debt with other objectives.
In this case, I would say they'd done such a good job with managing technical debt that they knew they could say "as long as it takes" on a micro-level, and be confident that nothing would blow up on a macro-level.
This was a physical system that has annual (or semi-annual) inspections by a third party. Can you say the same about your software system?
I’m often bemoaning the “Silicon Valley Bubble” that people are caught in on HN. I guess I fell into the related “Software Developers Bubble”.....
Point taken.
A manager asked a programmer how long it would take him to finish the program on which he was working. “It will be finished tomorrow,” the programmer promptly replied.
“I think you are being unrealistic,” said the manager, “Truthfully, how long will it take?”
The programmer thought for a moment. “I have some features that I wish to add. This will take at least two weeks,” he finally said.
“Even that is too much to expect,” insisted the manager, “I will be satisfied if you simply tell me when the program is complete.”
The programmer agreed to this.
Several years later, the manager retired. On the way to his retirement luncheon, he discovered the programmer asleep at his terminal. He had been programming all night.
There are very, very few managers who are realistically in a position to be able to say something like that.
There's a good chance you might be working for a nice guy / purist / engineer's manager ... but who might actually not be a very good manager at all.
If 'getting it right no matter the cost' were a good company building philosophy, we'd all be doing it!
'Getting it good enough for the market to accept given a limited budget and timeframe' is basically how 99% of the world must operate. It's just reality. That's why being a manager or starting/owning/running a business is hard. Usually really hard.
A good manager knows this and will give you room to find that balance yourself, unless you have demonstrated you need help with that.
[1] Or at least I've never heard anyone else use it who didn't get it from me.
IMO, good judgement about the things that need to be right enhances the ability to make money. Too often I see manager-type people disregard the technical grievances of a team as ambiguous/unimportant things, while at the same time wondering why nobody can deliver and get things done. There is very often a direct connection!