How I Under-promised, Over-delivered and Screwed Myself | Hacker News Reader

How I Under-promised, Over-delivered and Screwed Myself

nathanconyngham.com

80 pointsboyter59 comments

A better title:

"How I didn't know how to under-promise."

I did freelance web design in high school (nothing fancy, HTML/CSS with stuff that clients thought was fancy in 2006, like Lightbox and RSS) and after my second client, where a five-page photography portfolio turned into a Frankenstein's monster of a PHP web-app held together by duct tape and invalid code, I realized two things:

1. There is never such a thing as being too specific.

2. Bill hourly.

3. Never do "cheap mates-rates" for friends & family, or this will apply...

2. Bill hourly.

Bill weekly, or at the least daily.

I agree, but when you work nights/weekends it's often hard to do so.

You mean "bill time & materials". Hourly is just one way to do that, and it's an especially painful and counterproductive way.

Corollary: get a deposit.

I agree. I think the relatively-green consultants here would get some value out of you expanding on how T&M can work for them.

I certainly would. Even after 7 years of successful work, I've still not got billing sorted.

Fixed-price jobs generally take double the time (losing me half); sprints work if the client understands and is in charge of the project, but most see it as a cost-sink and nothing will be delivered without extorting extra cash (which a long-time fixed-price client spat at me last week...).

Fixed price bids are better when you've already established a working relationship with your buyer. A good way to establish a working relationship is by starting off fixed-price if the scope is narrow enough and explaining that T&M is more likely to be more expensive for the buyer based on the scope.

Usually this results in the buyer either:

(i) asking for a lower price;

(ii) disagreeing with the FP bid and going T&M;

(iii) walking away.

The basic assumption is that scope is narrowly enough defined. If it isn't, then try hard to narrow the scope and give the deal 1 to 3 hrs for this exercise (depending on your available hours classified for business development aka "biz dev"). At this point, hopefully you've got the requirements narrow enough that you can then engage in the exercise above after coming up with an estimate or quote.

If (i), then roughly itemize and remove items to bring the price down to change the value proposition. Avoid keeping scope the same and bringing price down, or else this is a plain discount pure and simple and hurts you down the road.

If (ii), then the follow-up move for future deals with the same buyer is to clearly show why their final T&M billables could have been cheaper if they'd gone with FP.

If (iii), count yourself lucky. Nothing harder than letting business go until you get yourself into a deal where your costs are higher than revenue (aka. negative margin deal).

>>Fixed-price jobs generally take double the time (losing me half)

... that sentence implies a pattern of failed FP deals and lack of scope. However, I am empathetic because other clients have stated that they are uncomfortable with code sprints on a professional services basis solely because of the lack of concrete deliverables that can be used as payment milestones or triggers.

Code sprints are better off billed on a T&M basis unless, as you say, the client really understands what they're doing. In most cases, buyers don't know what they want, which is why some time must be spent on building on biz dev building the pipeline.

Thanks. I appreciate this.

Could you define T&M in this context? How does it differ from code sprints?

> If (ii), then the follow-up move for future deals with the same buyer is to clearly show why their final T&M billables could have been cheaper if they'd gone with FP.

I understand (i) and (iii), but why is showing them FP is better than T&M a good idea? Isn't T&M more profitable for me?

> ... that sentence implies a pattern of failed FP deals and lack of scope.

That's accurate unfortunately. There's always scope, but for sub-£2k jobs (and worse for sub-£1k) there's a trade-off between time spent tying down the scope and time doing the job. If I spend an hour on it, that's 5-10% of the overall budget gone.

T&M is "Time & Materials", which is the same as billing by the hour or week. The advantage of T&M for code sprints is because of the typically ambiguous and uncertain nature of the sprints. Even though there's supposed to be a well defined and constantly prioritized queue of features to be completed during each sprint, the fact that they can be changed and moved around means it's incredibly difficult to nail down an actual deliverable beyond a vague "payment of milestone X due upon completion of code sprint", which is really no different than a duration-based payment schedule which basically boils down to T&M :D

FP is generally (not always) better for both the buyer and provider because:

1. Buyer benefit: For a given scope there is a corresponding, known budget. Typically, fixed/forecasted budgets are preferred by buyers so they can forecast and set internal expectations.

2. Seller benefits:

(i) If it's a task that you feel can be done quickly or with less effort than normal (e.g. done repeatedly for others in the past), you can still charge based on the VALUE of the work vs. the # LABOUR UNITS, ultimately resulting in a higher margin for the seller with a tightly scoped budget for the buyer, even though it takes you less time to complete. The only time you need to consider lowering list prices for work done several times in a row is when a perception of commoditization creeps in, either by the general industry or (more likely) by the customer(s).

(ii) T&M is more profitable for you in the short term, but often causes more overhead and problems for the buyer on larger deals as scope uncertainty and ambiguity increases. Typically, the easier you make your buyer's life in terms of reducing overhead and paperwork, the more likely they are to want to work with you in the future.

>>There's always scope, but for sub-£2k jobs (and worse for sub-£1k) there's a trade-off between time spent tying down the scope and time doing the job.

Sounds like you're an independent freelancer. In this instance, you're in a tough spot. I suggest putting in 1.5hrs that you swallow from a cost basis with a firm goal to minimize potential risks during the engagement.

The worst part of being an independent is that your overhead is typically higher if you try to go the FP route for higher-valued deals as you are solely responsible for writing the SOWs, thinking about the timelines, managing the customer AND delivering. I can absolutely understand why, in that situation, you're comparative advantage is defaulting with T&M in most situations and hopefully raising your prices a bit to compensate for the inevitable pre-sales discussions you need to have with potential customers.

Sorry I can't give more advice there. I've found patio111's posts to be very informative for independents looking to grow.

I think Nathan's got the meaning of the phrase mixed up. The idea isn't to promise your standard output and then run yourself into the ground trying to exceed that. The "under-promise" part means that you promise less than what you know you can deliver. Having done that, you deliver your standard output and thus have "over-delivered". In this manner, it's sustainable.

Either that or he thought that they were under promising and with the over deliver they would be at standard workload. I think it turned out that it was harder than expected to continue their over delivery pace.

The trouble with actually under-promising on a project is that unless you have actually done almost that exact project in the past, or are a fantastic pessimist, you will fail to under-promise. See http://lesswrong.com/lw/jg/planning_fallacy/

Which is why you're under-promising. So that when inevitably things don't go as well as planned, you have a buffer.

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Actually, you just get better at estimates. 10 years in I am finally starting to get the estimate formula... and it's about as simple as someone told me:

every time anyone gets an estimate, double it. so, you estimate yourself, double it before you give it to a manager. the manager should double it before they give it to a client. the client should double it before they give it to their finance department... and you'll come out on budget for the project.

A friend who is an architect says that pretty much every project they do gets a 3-5% allocation for 'contingencies'. Then the client usually starts trying to 'trim the fat', and the first thing out the door (over protests) is 'contingencies', because 'they're not giving us stuff'.

Sure enough, when the soil is getting turned, there's a need for more cash to do unexpected -foo- or increased price of -bar-... and now the project is 'over-budget'. And almost always wouldn't have been if the contingencies fund wasn't removed.

In the proposed contracts, is the contingencies portion refundable if unused?

Contingencies in construction should be reduced or eliminated as the project proceeds from conceptual phase to design and more information is gathered. The contingency line item should almost never be carried over into the construction phase for vertical construction and if the project comes in over budget it speaks more to the failures of the design team at estimating than to a budgeting failure.

Other types of construction may indeed carry contingencies through construction phase but it must be made absolutely clear to the owner of the project that the contingencies are for X unknown and not just a "we can't estimate very well so hit it with 10%".

I may have inserted the 'turn soil' part - thinking back, he didn't mention anything either way about the phases, just that routinely it was the first thing sliced out, and it came back to bite them later each time that happened.

Is there a name yet for the fallacy of calling everything a fallacy? Back then, that word used to mean something.

I think you misunderstand, not he. By under-promising he lowered the value of his standard output, because the client adjusted their cost expectations downward.

I did this on my first real consulting gig on a state contract. We were on a roll kicking ass working 10-12 hour days and we blew through the requirements in the first deliverable a month early. When you're going like that you don't want to stop.

Rather than taking it in and showing them. The lead decided that we should just start in on the second deliverable.

We busted out most of the work there before the meeting began regarding the first deliverable.

When we went in to the meeting we were shocked to see that everyone who had written up the requirements had quit and moved on to other jobs. The task had fallen to other employees who wanted to completely change the direction of the application. While the first deliverable did not change. All the work we had done on the second was worthless.

After that I never again worked 12 hour days while on schedule and I never again did anything ahead of schedule that wasn't a 100% sure thing.

It would have been fine to get the first deliverable done early. I'm confused why the lead (or whoever was responsible for invoicing and managing the customer relationship) didn't invoice right away.

The team still could have gone ahead with the second deliverable "at-risk" (i.e. on the assumption that the customer still wants the next deliverable). The key failure point here was the touchpoint with the customer and the invoicing. If there was no payment trigger/invoice for the first deliverable, that only emphasizes the importance of the customer checkpoint.

Usually, the project manager (sometimes known as the engagement manager in other shops) is responsible for this. That person failed the buyer, your organization, and your team.

I don't really understand why it went down like that either. It was the lead/PMs first job with the company and mine too. He may have been concerned with losing face or he wanted to finish the whole project super early and possibly get a bonus because it was fixed bid.

The requirements doc was extremely clear and robust. We felt confident that we were on the right track. Regardless I pestered him to schedule a meeting right away. After two weeks he relented but it took us another two weeks just to get in there due to people leaving at the state, general confusion over there and I assume them spending time rewriting the second deliverable.

There are a number of things we could have done to avoid the grief on our end.

1) We definitely should have made a greater effort to get in there as soon as we were done with the first deliverable.

2) we could have not burned ourselves out working 12s in the first place on salary and finished about at the right time when they were ready for us.

3) After finishing early we could have taken the equivalent time off instead of trying to power through the second deliverable. (not getting ahead of ourselves or burning us out)

We ultimately delivered the project within the time constraints of the estimate (a miracle considering we lost almost a month). although not including the OT we spent initially. So the client was happy but our team's morale never quite recovered.

To sum up: just promise what you can deliver, deliver what you can deliver, and stop playing games.

Honestly, I've found that the value of even simple web applications in modern business is so enormous that once you have your foot in the door in a place the contracts just dont stop coming. Especially when you were intelligent enough early on to be selling them an ecosystem, a complete automated solution to their problems, instead of a single, one-off application. The price of going out and developing a good relationship another contractor who is capable enough to understand your existing code becomes prohibitively high, especially when they already have a good working relationship with you.

Is this cynical? No. I'm not suggesting that you slack off or deliver substandard products. I am making an accurate statement about the value of IT in the marketplace. It just reflects the business reality of the moment: people who can make applications are still rare, these applications are immensely valuable to businesses, and if you can do them, there will be someone to pay you to do so.

When competition becomes steeper you can start to play games with expectations. Until then, never let the company intimidate you into thinking they're doing you a favor by giving you a longer deadline. You're doing them a favor, assuming the product works like it should. Deliver and promise exactly that.

I love that the OP put this out there as a learning experience. Regardless of the fact that he has an MBA and a technical background, he cheerfully admits he was wrong and tries to do a better job managing expectations in the future. I'll provide a blow-by-blow analysis.

>>“We need to under promise and over deliver.”

Great! But, why? There has to be a concrete, preferably measurable, reason(s) to have this mindset. As other commentators noted, what he did wasn't really under-promising, but simply adhering to the original schedule, which implies that the customer was on-board with the agreed timeline.

>>The project moved along and thanks to some long days we actually managed to deliver functionality ahead of schedule.

What did he expect to get out of this? What did he tell the team to justify this?

>>We continued our iterations, tuning functionality and consistently over delivering when the team started to become disgruntled and exhausted.

Even with the right motivation, burnout is a constant issue for services staff in any industry, especially when the engagement lead doesn't monitor both sides (customer and internal). He would have monitored this more closely, or would not even have gone down that path if his internal team were billing him on an hourly basis, as it would have forced him to more concretely justify to himself and his partners what he expected to get out the self-imposed accelerated schedule.

>>To continue to over deliver, the team had been working very long hours, weekends and some had missed important family appointments.

Live and learn. Seems like you are somewhat charismatic, or have a hold on your employees that made them put in the long hours and miss family time without pushing back on you.

>>The next day we presented to the client, they were surprised at what we’d achieve in such a short time and were happy that we were ahead of schedule.

As engagement manager, you should have ensured that this wasn't a surprise to the customer! It would have allowed you to more quickly gauge whether (a) it's worth continuing on the death march and (b) how the customer will react.

>>The discussion turned to the next set of deliverables, the effort and the expected delivery dates. This is where it all started to fall apart.

No -- we need to be very clear here. Things started to fall apart well before this due to: (i) lack of identifying value exchange for the death march on the first deliverable; (ii) lack of continual communication with the customer.

>>“Why can’t you do it? We’re not asking for anything more, it’s actually less than what you delivered before.”

The standard answer here is:

(i) We can't do it because the first deliverable was a one-off to help you reduce time-to-market / internal target date, but this second deliverable will require additional staff that I don't have. From a resourcing perspective, I'm not going to charge you for the additional hours that my staff spent on the accelerated schedule for the first deliverable because I made that decision unilaterally. We must stick to the same duration for the second deliverable.

(ii) I know you're not asking for anything more; that's why we're able to commit to our originally agreed upon deliverable duration (e.g. 2 weeks), and nothing shorter.

(iii) If you want us to work weekends, as per the Statement Of Work ("SOW") that you signed, you'll need to pay for the additional weekend and holiday staff shifts for the second deliverable [context: sounded like the OP did in fact have a contract in play, and hopefully had language in the SOW that covered increase in base rates for weekend & holidays]. We'll swallow the increase in costs for the first deliverable because we did it of our own volition.

(iv) I'm glad that we confirm our original agreement regarding the nature, specificity and scope of the second deliverable (i.e. that it is "less than what you delivered before"). This further emphasizes that our originally agreed upon duration for the second deliverable is firm and we can deliver with the agreed upon duration.

>>Over the next few meetings, with significant effort, the discussions started to turn around. I had been reborn and now realised:

There's hope for you yet! In most situations, this is where the customer escalates, goes over your head and tries to get you off the project, or where the firm partner/general manager tries puts a PIP on your record because your customer relationship management skills (the number one reason you're typically chosen to become an engagement manager) was so severely lacking. Seriously, that was a great turnaround if the OP did that himself.

>>It’s not about the effort, it’s about the outcome. The client did not care how much effort we’d put in.

In general, this is true. However, as part of your job you are supposed to tie in the effort with the outcome, whether via narrative, task-based estimate or simply pure dollar terms. Do this, and your job becomes easier explaining timelines and pricing deliverables.

>>We needed to become a partner

Yep. However, as part of your job, you must be cognizant when a psychopathic or aggressive customer has no interest in becoming a partner and only extracting as much value as possible out of the current deal. Customers can flip, and engagement managers must always be taking the customer's temperature to protect the deal, the team, and the deal margin.

>>The expectations had to be reset

As others noted in this thread, they weren't managed properly. OP was fine up until the kick-off when the baseline timeline was established and agreed upon, but then went off plan for no compelling reason(s).

>>As painful as this was, it did teach me a lot. Get on top of this before it blows out.

Amen.

>>Under promising and over delivering is for suckers.

This last sentence is wrong. Forget about under promising. Just focus on the over-delivering part. Only over-deliver if you have the appropriate risk appetite, enough deal margin you're willing to sacrifice, and compelling exchange of value. Examples of exchanges of value are:

(i) "If we make a great impression that is sustainable in the long run, we can leverage this influential customer for references in the future!" --> Make sure your sales team has the balls to follow-through on this. Surprisingly, many organizations and field teams have a hard time asking for references for future deals.

(ii) "When we were talking, the customer kept referring to feature X that's gating the next phase of their program and holding up future deals. If we deliver a proof of concept showing that we can deliver this functionality, it might clear the obstacle for future services deals." --> Make sure your product/engineering group can deliver, and that your support group will actually support the new 'feature' that you deliver.

(iii) "The customer is asking us to bring in the schedule. We've got no other deals on the table and all of our guys would be on the bench (i.e. idle) otherwise. Let's swallow the cost for a short period of time." --> Engagement manager needs to go into 'expectation management' overdrive and find a narrative that works for both parties.

If you had to put in ridiculous hours to hit the under deliver timeline, you in fact over promised.

That was my thought too - why did they not put in sane hours and deliver as promised, instead of killing the team to overdeliver?

This sort of expectation management is also why it is a terrible idea to show a client a slick UI mockup that kinda works (but is missing the underlying app logic).

As far as they are concerned, you're pretty much almost done because all the stuff they will ever see is there and looks good. No matter how much you try to rationally explain to them that it is just a superficial shell of an app and is a long way from done, a lot of them just aren't capable of internalizing this concept meaningfully.

What's the best way you've found to manage that particular issue? Line-art slide decks instead of interactive demos?

In my experience, yeah that's basically it. If it helps to have an interactive demo to communicate things, keep it ugly when showing it to the client, and show them the final UI designs separately as static image files. Even if you've already done the work to bring the assets into the demo, avoid showing this to the client as long as is reasonably possible to manage their expectations because they will almost universally have a hard time separating the UI/UX functionality completeness from everything else.

Obviously there are situations where the client will, in fact, understand the distinction, but I assume they won't until proven otherwise.

Because it's so easy to make slick mockups a lot of developers have forgotten that lo fi prototypes are a Good Idea, but obviously you're also selling against folks who will show clickable prototypes that look finished, so it's a matter of building a relationship where you can avoid this kind of silliness.

Expectations management is probably the most underrated skill in the world. (Cough Obama Cough.) The problem isn't the idea of underpromise and overdeliver, it's not realizing this is about expectations management (it's also about only thinking of the idea in terms of customers -- your team needs to be treated well too).

First of all, pad estimates realistically, add contingency estimates, trade off deliverables against shortened schedules, and then you're in a position to underpromise and overdeliver and not screw yourself. Oh yeah, and don't deliver early, ever. Wrong axis to exceed expectations on. Deliver more features than originally promised, or more polish. Never create expectations of faster delivery, you shoot yourself in the credibility.

Oh yeah, and don't deliver early, ever. Wrong axis to exceed expectations on. Deliver more features than originally promised, or more polish. This is the most important thing. Under-promise, as much as you can. Get what you promised done - with normal working hours. IF there is still time, do something more (a little, nice to have feature, or polish). Deliver on time.

Having hired many software development firms for projects, I expect the project manager to ensure the consulting team is not working inhumane hours and to push back if I ask for too much, too soon. Healthy push back should normally come in the form of "What you want will take an extra developer, an extra month, an extra $20k, etc." and let me decide if I still want to do it. If the firm fails, then I fail, so I never intentionally do things to undermine the consultant, but I am also not perfect and depend on honest communication from them. Also, a project done ahead of schedule is not as helpful as it seems. Even if the consultant is done early, it doesn't always mean that I can start my next milestone early.

And then when the managers rely on pushback from engineers who don't know how to say no, they burn out and the whole thing blows up.

I still don't understand how our industry makes any forward progress in the aggregate.

Worse: engineers that think they gave a clear and well-reasoned 'no', but their manager is left with an entirely different takeaway from the conversation.

If you are a manager, it is a valuable skill to be able to actually hear "no" from the developer, which may come in many different flavors, but only a few will actually say "no" plainly clear.

On the other point, this seems more like a US/India thing. In Europe, where there are certain regulations about working hours, mobbing, and in general, higher employee protection by law, people are not that afraid to say "no" like in the US, but it's still not always clear and loud.

I guess centuries of taking heads from people saying "no" have taken its toll, and it's still hard to say "no" to superior.

35 years has taught me that saying "no" as an engineer means you are being an "obstructionist" or "not a team player." I am most definitely one of those because I was taught to say "no" very early on. The problem is that many people are affronted when they hear "no," take offense to it, possibly because it is a rejection, or, and this happens more frequently, a "no" answer to a lot of managers means "I just didn't ask you to do this persuasively enough."

Why can't you do it? We're not asking for anything more, it's actually less than what you delivered before.

Don't let a client, or anyone for that matter, corner you w/statements like that.

Regardless of whether they were right or wrong, in terms of the amount of work they're asking for being less than the previous, have something to show in regard to why it's not as simple as they perceive.

For example, consider adopting a thorough estimating strategy, broken down into small iterations of work. An estimate showing the amount of hours or calendar days the next iteration would take, accompanied by more realistic dev-hours-per-week (burn rate), would have been the right way to counter the client's statement. It's much harder to argue with with supported numbers.

My grand plan to under promise and over deliver had led to a disaster!

Any plan where you take on more work than you can handle in a given time frame will lead to disaster. Under promising and over delivering had little, if anything, to do here. This was entirely a management problem (dev schedule, client expectations, etc.).

> It started with an internal meeting that focused on the expectations set and how we were going to now deliver. That’s when it happened. I blurted those horrible words out. “We need to under promise and over deliver.”

Dude, those are the words to live by. Not marketing spiel. By saying it to the client you did the exact opposite. You over promised.

There are lots of different types of clients. Some use your response to their first request as a measure of your standard output. Once that is known, a difficult client might continue to demand more.

I've found this happens often with clients who are the least knowledgable in your area of expertise. Sometimes their insecurity compels them to avoid getting screwed, by making sure they're getting everything they can out of you.

Other clients, with lower expectations, might be overjoyed by the the same efforts. All clients are not equal.

tl;dr: OP failed to under-promise correctly.

One think I learned from these type of situations is that it is important with some clients to stretch how difficult the project is and keep a constant flow of signals that show the hard work we put into the projects. In my perspective everything is super difficult. Unless the client knows that it is super difficult then it must look really easy. But it is a very nuanced approach, not that black and white as I describe it.

The client must take away the feeling of "they moved heaven and earth for me and I really can't expect them to pull such inhumane hours for me next time" and not "well, they clearly can do a lot more if I just challenge them a bit more". It depends a lot on the client relationship and the related communication.

I recently had a waitress who "moved heaven and earth for me" (that's the phrase she used over and over and over again and again and again). I don't doubt that she got the cook to do a favor for me, but hitting me over the head with it until she was blue in the face actually made me lower my tip.

As in all things, there's a balance - having the client understand that it wasn't a cake walk is important, but not beating them over the head with it is important too.

Over-deliver doesn't mean "deliver early." It means deliver better quality.

Because if you let a software deadline slip, you'll be the first person to ever do so...

(I like the whooshing sound they make as they fly by.)

If you had to pressure your team to over-deliver against the first under-promise milestone, you completely failed Project Management 101. The point of "under promise, over deliver" is to give your customer a risk-realistic timeline that you can likely exceed, but which won't disappoint them if your project runs into speed bumps.

They just didn't underpromise enough. They should have promise only what they could deliver with half of the team working 3 days per week and overdeliver things by making 3/4 of our team working 4 days per week.

They would have happy and amazed client and lot's of spare strength.

he is very right, you can't make yourself work so hard and show nothing for it except everyone being too tired to continue working. And you giving someone a false image about yourself can come back to bite you when they expect you to always be like that and perform the way you showed them or better..

"Do I care how long it takes a mechanic to fix my car? No, I just care that its fixed."

Really??

Yep. If - like most people - you know nothing about cars, then you wouldn't know how long it actually takes to fix your car. So if the mechanic chooses to 'over-deliver' by fixing your car in 3 hours, instead of the actual 6 hours it takes, that's going to set your expectations. You'd think that it takes 3 hours to fix a car, and you'll be pissed when the mechanic takes 6 hours the second time around. Which was the problem the author faced.

Mechanics don't even charge how long it actually takes. They charge a standard (arguably, over-inflated) amount for a job regardless of the actual time.

So it does take 3 hours to fix your car, and they charge you for 6. Then you care.

I'm not a mechanic, and know little about cars. However, whenever I've taken cars in for service I find that the shops charge me labour and parts, and they are often clearly itemized on the invoice.

The reason that it seems they charge a 'standard' amount for a job is because certain jobs (changing brakes/tires/oil, general checkups, car detailing, etc.) have been enough times across the industry and in the shop that reliable statistical (or consensus) baselines allow one to more easily and reliably estimate.

Admittedly, this doesn't fix the original principal-agent problem[1], but I thought I'd throw in my experience with mechanics and getting cars serviced.

[1] http://books.google.ca/books?id=4XcR7Y5ddcoC&pg=PA323&lpg=PA...

AFAIK, service stations even have catalogs (from manufacturers, no less) which specify how much time specific repair will take. Clients are billed according to that, and not the actual amount of time mechanic spent.

I misinterpreted your statement. You are right -- if an unscrupulous mechanic tried to charge you for more hours of labour than what the catalogs specify, then we'd care and would probably pick up on it a lot faster.

Yeah, that's not how you do it.

1. Under-promise for a sustainable output pace.

2. If/when you finish early, everybody gets an appropriate amount of time off.

3. Repeat.

Your client is happy, and your team is happy, healthier, and ultimately more productive.

Reply on news.ycombinator.com