Hacker News new | past | comments | ask | show | jobs | submit login
Deadlines Are Killing Us, and Almost Everything Else I Know About Leadership (medium.com)
256 points by Elof on Apr 1, 2019 | hide | past | web | favorite | 128 comments



Deadlines are effectively reality for many projects because tons of people and scares resources need to planned around them. Rallying against them is unrealistic

Let me give some examples:

You're making a product for retail. The stores that will carry your product need to plan to have their shelves full of product. That means they need to know when your product will be available. What promotions will appear on posters, flags, etc in the store. They need the plan this 6 months in advance so you have to commit to a deadline well beyond your finish date.

You plan to run commercials. The TV companies need to know sell their commercials months in advance. So you commit $$$$$$$ to pay for those commercials 6 months in advance. Miss your deadlines and there will be no product when your commercials run.

You're adding features to a mobile OS. Your partners (Samsung, or Sony, or LG or Motorola) are planning all of the stuff above (PR, Commercials, retail placement). They are going to be touting your new feature. Because they have to commit to ads and shelf space months in advance you also had to promise your feature will be ready months in advance.

I'm sure there are better examples. Here in Tokyo they getting ready for the Olympics. The venues, transportation changes, etc have a hard deadline.

Video games used to (still?) have all the same issues. 6 - 9 months before Christmas you have to promise the stores your game will be ready and on their shelves. That may change in the future but even in 2019 retails sales of bluray PS4/Xbox and Switch SD games are greater than online for the majority of games.

If you happen to be on a project that can run without deadlines and things get done and shipped whenever then lucky you.


If a project must have a deadline then I think there needs to be flexibility on what features are included.

For some features you can only know how long they will take once you get started on them. The overall business requirement has a deadline, but individual features may not.

The worst kind of deadlines I've experienced are we must have X by Y date, where the Y date is imposed by someone outside of the team without really thinking it through, and the only way to achieve it is via overtime and cutting corners.

This can also happen when you the dev says "10 days" then they get haggled down to "2 days" by their boss. Having split the thing up into 100 pieces and have those pieces individually negotiated, you end up with a hack solution. That kind of project, one way or another is going to go to shit. It may be delivered on time but it'll be a turd. Or it will just be late.


Absolutely. I’m in the midst of a project like this right now. PMs and Devs suggested a launch date of August/September but the Execs arbitrarily mandated mid-April. So, design gets rushed, Devs have to work overtime and half bake everything, and what should have been a great new venture for the company is probably going to be dead on arrival.


> where the Y date is imposed by someone outside of the team without really thinking it through

From my experience this is arguably the biggest factor I have seen for a project to fail. Not all realistically planned projects are successful but unrealistically planned projects become woolly very quickly.


It's truly amazing how few people can grasp the concept of the time/quality/cost triangle.

If you want good quality in a short time -- it'll cost more.

If you want cheap -- you have to compromise on the amount of time or the quality.

I'd argue resource is a better metric than "time", but the point holds for the most part with either.


> when you the dev says "10 days" then they get haggled down to "2 days" by their boss.

Devs are typically optimistic in their estimates. Having someone who won't do the work put any kind of downward pressure on an estimate is a great way of getting uninformative estimates.


In my experience this is largely a function of environment.

If you give a realistic estimate and constantly get "stop padding your estimates" or "this needs to be done quicker" in response, after a while you start giving hopelessly optimistic estimates.


You might be right, however what I've often observed is that people will estimate a task based on how long it would take them to do it if that were their only responsibility. They often ignore the fact that they don't get a full days worth of solid, productive coding due to meetings, build problems, releasing, code review, recruitment, fire alarms, sickness, status reporting...

As I recall, at IBM they used to give 3 estimates, best / expected / worst case, and then weight them something like 1/3/5 to get the planning estimate.

One person I worked with recorded estimate vs actual for multiple years. They were frequently an order of magnitude out.


It’s nuanced.

Artistic things can have deadlines more easily because you can simply decide what constitutes good enough.

Functional things have to work...or they aren’t shipping. They can decide good enough on refinements and UX...as long as it works.

It that sense, there are very few real deadlines around functional things. If it doesn’t work, it’s not shipping yet...meaning it’s not really a deadline.


[Pet peeve: nuanced is overused.]

Not really, choose feature specs or choose a date, not both. Even non-artistic things can have dates, just look at Ubuntu (and now Java) releases.


> [Pet peeve: nuanced is overused.]

I'm used to seeing (and feeling) the inverse: people are far too likely to sum everything up into a simple, but too often wrong, explanation (he says with irony) Care to explain your reasoning for why it is overused?


I agree that too often sweeping statements are made and there are cases where finer details matter, and...

I see it as a form of one upsmanship, like wine tasting when the term is used. Other times, it's used to suggest that there's some detective work going on when the case is not so subtle or sometimes even incorrect. Or maybe I just have a narrower definition of subtle. I also prefer to use the term for analogue things rather than discrete ones. No matter how small a discrete case is clear cut.


I agree with you. Nuance is something you don't see acknowledged and used sufficiently. Everything is made to be black or white when it's mostly grey all of the time. At the same time, constantly staying in nuances prevents you from moving forward, so there's that.


And when Ubuntu has a date, if something isn't ready by that date it doesn't go into the release. Simple as that.


Deadlines are also a way to manage resources and priorities. If something doesn't work, knowing when that thing needs to work by helps you determine if it's worth it to add more people or pay extra overtime, etc.


Well i don't think it is easier with the Artistic things. For exactly those reasons you mentioned never know when the work is done. It's also hard to estimate how long stuff will take and people fall asleep meaning you might be less intensive in your work than you should be because you have no idea you are behind schedule.


That’s not really true. Define “works” if I’m adding the ability to export a document. Is .txt enough or would my users actually want an image? Or a pdf? Or at least .csv? Maybe .txt would satisfy the power users but just upset the less computer savvy ones? Is it better than nothing?


If you have a release deadline for a quarter and PDF export is supposed to be part of the release, if the export does not work will you ship the feature?

You're either going to "hold the release" or you're going to release without the feature...because shipping with the broken feature will only create a huge support burden and a negative perception of your product.


Yeah this is a weak article. Engineering has always involved deadlines.


I can't find the exact quote, but I think it was Aristotle who said (something along the lines of) "we haven't mastered the art of teaching, except to those for whom it is superfluous". This is still true today, and, I think, true of each and every single management fad. Things like deadlines, status reports, daily standups, open offices, tickets, and retrospectives are designed around the assumption of a reluctant workforce who have to be clubbed into line. If you assume that's what you're dealing with, you're going to gravitate toward heavy-handed means of control and conversely, if you gravitate toward brutal overseer managerial tactics, you're sending the signal to the workforce that you expect them to push the envelope and accomplish as little as possible within the narrow parameters of your dictatorial cruelty. If you assume that we're all on the same team, you'll get good results as long as we are. If you assume that we're not, there's no level of threatening or punishment you can dish out that will.


> the assumption of a reluctant workforce

From interviewing hundreds and managing dozens, I'd say that this is unfortunately largely accurate and not through anyone's malicious intent, but just human nature.

A good salary helps to mask the reluctance, but deep down most people aren't living their lifelong dream at their day job.

There are many other things we'd rather be doing with our time and I think good managers understand and accept that. Some people are just off the charts innately consistently productive, but most aren't and need motivation to stay focused. Deadlines are a tool that works for some people. Others need praise, others need purpose, others need creative freedom. But deep down I think most of us need some external motivation to stay focused for 6-8 hours a day.

But when you do find that person that can consistently self-motivate, hire them and keep them. It makes everything so much easier.


I know that some people do find their dream job but most people cannot - trying to demand that people love their occupation is too extreme for me. Make working a positive experience, fairly share the fruits of their labour with them (allowing them that pride and connection with their production) and you'll find most people respond positively.

Some people may legitimately just love working but that isn't a reasonable expectation.

All that said, I think deadlines are terrible, they create a sense of cram and ease which works people out of a habit of working while at work. It's better to hide deadlines at the management level and make sure everything is comfortably budgeted, then just transition from one project or task to the next smoothly, without rushing pressure or the "months" scale of doing a thing that can cause it to never be done.

I worked in a job where overtime[1] was the norm for a while, I hated it, put on stress weight, and don't wish that lifestyle of zombie living on anyone. It builds up extreme resentment and lowers productivity so, as a manager, realize that if your project is pushing a deadline you, the manager, have failed utterly. Then seek help from your employees and try and get it done on time, be open about your mistake, make it clear how you'll address it and, seriously, keep overtime and deadline press to the exceptional case rather than the regular.

[1] Oh hey, for bonus points... where I work in BC overtime for tech workers is, by default, uncompensated... and we have nobody but EA and a compliant local Liberal[2] party to thank for that stupidity.

[2] Not liberal as in leftist, "Liberal"... in fact "BC Liberal" is a term up here as they are the most conservative of the parties.


I'd agree and also like to add that after seeing many teams without any imposed deadlines or pressure, I can tell you those teams who are "free to roam" also end up even more frustrated and unhappy because they often feel less part of a success story and ultimately that they're wasting their time.

Time boxing projects teaches people to innovate and become more resourceful. I've seen endless scope creep since starting at my latest company where people aren't help to any type of deadline.

I think the best approach is to have deadlines but allow teams to workout how they manage their time during that window.


I don't think anyone has to love their job or think it's their lifelong dream for the theories of the OP to hold. They may have to not _hate_ their job, not dread going to work.

Very few people are going to want to be a janitor as their lifelong dream. But there are plenty of janitors who take pride in their work, and pleasure in keeping somewhere clean and tidy, and being appreciated for it. Doesn't mean they wouldn't rather be somewhere else much of the time, but as long as they're doing it they find it rewarding to do a good job.

And you know what's going to make it more likely to have that "kind of" person on a janitorial team? Giving them autonomy, trust, responsibility, psychological safety, appreciation and recognition, etc.

And what's going to make it more likely to have janitors who hate their job, take no pride in it, dread going to work every day, try to get away with the bare minimum, etc? Micro-managing, punishing, not giving them autonomy to do the job in the way it makes sense (as they know best as the one doing it), inconsistency, lack of ownership, lack of recognition.

Because it's not a "kind of" person at all. Some people individually wind up in jobs whose duties necessarily have aspects that are intolerable to them personally and ruin their day, and it would be better for everyone if they could find a different job. But if you are managing or working with a group of people who all or mostly seem to be like this... you didn't hire the wrong people, there's something wrong with the environment. (There's something wrong with a very lot of environments).

Or, as OP says:

> When we try to control people, they become less motivated, less inspired, and less innovative; they do the bare minimum work or they just leave.

(And if YOU are in a place where you hate your job, dread going to work everyday, only want to do the bare minimum to escape punishment at it -- please, for your own sake, try to find another! I know that's sometimes easier said than done and you gotta make rent somehow, but if you are in that place it is destroying your soul and sense of self! You know it, you're miserable -- and it does not have to be that way)


Agree. Also more than human nature, it's a highly competitive world.

If a manager in the org, is producing results using a heavy handed approach, you can be sure your boss is going to be knocking on your door to have a little chat about "improving things" in your teams. It's not a bad thing. Pushes good managers to evolve their own systems.


There is also the approach of only keeping the people who self motivate. I've been in a organization like this a few times in my life and it's fantastic.


"Things like deadlines, status reports, daily standups, open offices, tickets, and retrospectives are designed around the assumption of a reluctant workforce who have to be clubbed into line."

I recently read a RAND Corporation research paper from the early 90's about command and control, and it gave me new insight into how a C2 system supports a commander (or in a business case, the CEO).

The things that you mentioned (status reports, daily standups, tickets) are not for "clubbing the workforce", they are for feeding information to the CEO/commander about 3 things:

-does the organization understand the plan the way the CEO does? -is the organization executing the plan correctly? -is there information that requires the CEO to change the plan?

It's not about "the beatings will continue until morale improves".


Do you have a link to the paper as I'd be interested in reading it.



I seriously can't believe how many businesses think their employees are stupid, or that they can trick their employees. Word spreads, and people will hate you forever if they find out. It's just not worth it.


> we haven't mastered the art of teaching, except to those for whom it is superfluous

To put it another way...

We haven't mastered the art of teaching, except to those who have mastered the art of learning


    deadlines [...] are designed around the assumption of a 
    reluctant workforce who have to be clubbed into line
Er, no.

Sometimes it's the opposite of reluctance.

Lots of enthusiastic coders will code away endlessly, never shipping, unless there's some sort of deadline even if it's a self-imposed one. We can see this in many creative and/or engineering pursuits. A passionate writer may revise their work for all eternity without deadlines. Etc.


Did you mean this quote?:

"The power of instruction is seldom of much efficacy, except in those happy dispositions where it is almost superfluous."

It's from Gibbon's The History of the Decline and Fall of the Roman Empire (Vol. 1, 1776)

https://en.wikiquote.org/wiki/The_History_of_the_Decline_and...


At least some of the people 'responsible' for this current state of affairs didn't want things to be this way.

In responsible hands, the graphs and metrics from Scrum or Kanban can be used to demonstrate how policies are actively hurting the development team. The information contained in them can tell more tales than just how we could have gotten slightly more done this week.

There may be a lack of responsible hands. It could be that it always has been that case, and you have to promote processes that don't presume an adequate and consistent supply of such hands. I don't know.

But I do know that marching fast to a drumbeat with no clear destination is road to disaster. That Scrum as it is, and even as it was described, is a giant dumpster fire and I lay an over-large portion of that blame at Schwaber's feet.


> Things like deadlines, status reports, daily standups, open offices, tickets, and retrospectives are designed around the assumption of a reluctant workforce who have to be clubbed into line.

Certainly true in some cases but needing data from the areas and people you manage is an essential need of all management, no matter its style. Tickets, stand ups, daily reports, they’re all ways to make the employee or their work _legible_ from the outside. How that legibility is used is another matter.


I've noticed that thing too. People are incredibly sensitive to assumptions.

If you order someone to do X, they might, if you ask, the might. But assume that they will do X and you do it aloud, they more likely to do X than in any other case.

I have stolen because it was assumed that I would. And that's totally not my normal style of operation.


If you think that’s what stand ups are for, you’re doing it wrong.

Ours are five minutes long and usually about sharing what we’re all working on and talking about roadblocks.


Some people work effectively only if you micromanage them. Some work effectively only if you're hands off.

There is no one technique fits everyone.

As for deadlines, you cannot manage a complex project with multiple teams without deadlines. After all, if you're building a car, you can't afford to hold up everything while you wait for the wheel department to get around to delivering wheels.

As for me personally, without deadlines I tend to procrastinate.


> As for me personally, without deadlines I tend to procrastinate.

I agree. Deadlines are highly motivating and help me determine scope of work I need to do.

"Make a tool that does X. You have infinite time."

Me: "Great! Maybe I'll implement it in Rust, I've always wanted to learn that. Or maybe I just research for a few days what's out there. And I'll need to think about testing infrastructure of course and benchmarking..."

vs.

"Make a tool that does X. We need it by Friday so we can use it for Y."

Me: "Ok! I can probably whip up something quick and dirty in python that gets the job done!"


> "Make a tool that does X. We need it by Friday so we can use it for Y."

> Me: "Ok! I can probably whip up something quick and dirty in python that gets the job done!"

And this, when abstracted across an entire team or company, is what gets us unreadable code and hopelessly buggy software. Productive does not always equal effective.


This is a problem of incomplete specifications.

"Make me a tool that extracts, collates and graphs data from this spreadsheet. We just need it to run once this friday"

"Done, super fast, slightly buggy python script it is!"

vs

"Every month we need a tool to pull data from multiple sources, and push it to a reporting framework. It needs to be scalable and robust... oh and we need it by friday"

"Well, you're not getting it by Friday."

Deadlines should be a conversation, not a demand.


Fast<->Cheap<->Good/Pick 2 is up there with the second law of thermodynamics in its inviolability.


Meanwhile "I'll learn a new language to do this" when abstracted across an entire team or company leads to code that no one knows how to maintain when the one person who wrote it leaves.


I feel the same way about "clever" code. Most of the time "clever" code isn't really any more efficient than a naive approach, it's just a way for a developer to code golf at work by abusing / using uncommon syntax or idioms. Which is really a net negative since other people need to be able to read your code


Yep! "Clever" code always reminds me of Kernighan :

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."


It seems to me that the smarter someone attempts to appear the less smart they truly are. True intelligence appears as clarity.


The converse, when abstracted across an entire team or company gives us architecture astronauts that don't ever actually ship anything that works.


Great so we've established you want to be somewhere in the middle.


It's also what gets us great code and reliable software, when done properly. Engineering is all about tradeoffs. A major tradeoff is time versus... just about anything else. Deadlines help you know how to make that tradeoff properly.


One of the best old-school pieces of advice I ever got was "always throw away the first one". (Widely advised on comp.lang.perk.misc back in the 90s... Tom Christiansen is the name I've got mostly attached to it in my head.)

I'd read that as two requests.

1) "Make a tool that does X."

2) "Fast track a tool that does X by Friday so we can do Y."

The use the time prototyping X quickly to learn the entire space around solving the problem X, while mostly aiming to just solve the parts of the problem that will roadblock Y, with the agreement that this is only a prototype and while the Y team may choose to put it into production, there'll also be a much more complete set of requirements and specification of "The X tool", (which may well include Rust evangelism, proper testing infrastructure, performance benchmarking and scaling plans).

(Note: _most_ of the time this does not actually get acted upon, and I've got several hilarious war stories about "quick hacks to get us past next week's deadline" that out survived the company that I implemented it for. But a least I had it in writing...)


> always throw away the first one

That’s a quote from Fred Brooks’ The Mythical Man-Month (1975):

”[…] plan to throw one away; you will, anyhow.”


A deadline gives you the freedom to ship something imperfect.


For my own work, I find there's actually only a given quota of 'stuff I actually want to do' on a given day. If I'm not in a good place (health, mental health, etc) this number is much lower than if I were in a good place.

Generally I unconsciously categorize tasks that I remember I need to do* (or that a task list helps me remember) a kind of emotional score relating to their ease of accomplishing, the need to get them done today / sooner vs later, and how big a work slot I feel I have to pack them inside of.

I have noticed that tasks which are perceived as easy or quick to accomplish tend to get fulfilled faster; I can clear the item out of my mental list and it can be squeezed in to moments that would otherwise not be productive.

Tasks with external dependencies (meeting others, scheduling anything at all with anyone else, waiting on external approval processes) are clutter that stuffs up my mental caches, but isn't quite something that I can clear out either.

The inability to clear those things out becomes a type of stress, and creates a negative feedback loop of it's own.

Foreknowledge of those issues, as well as scheduling constraints for doing things, often leads to the estimation that a task which might otherwise be easier (for example if moving fast and breaking things) to cost more (only break things during limited, pre-announced windows).


If a person is self aware enough to know they need to be micromanaged than maybe they could request more hands on management. I think one of the points of the article is that many managers assume there is a need for micromanagement and over all that type of management is demotivating and hurts productivity and creativity. I’d argue most people want to do good work if their needs are met and they are in the right environment


Some people who don't think they need micromanagement actually do. The problem is they keep diverting and working on something else, and need to be continually reset back on to the critical path. A good manager will adapt to what works best for the particular employee.

It'll take some time, though, for a manager to learn that a particular person can be trusted with a hands-off style. I've tended to default to hands-off as a manager, sometimes with expensive results.


A good manager shouldn't resort to micromanagement even if the employee requires it. You're not supposed to be their secretary or mommy. A good manager would coach or train them to become more organized. A manager is responsible for supporting their employees' growth, but the employees also have a personal responsibility to develop their skills on their own.

In the long run micromanagement sets them up for failure. You're not going to be there for them forever. If they can't improve their organization skills to a point where they can complete work on their own, then they might not be suited for their job.


I've had the same experience as a hands-off manager. In almost all of those cases I should have let the person go instead of trying to improve how I manage them. Hind sight and all and choosing to let someone go can be difficult, but still


The ultimate guy who didn't need managing was Richard Feynman. Just put him on the payroll, and great things will happen!


I feel like the author is an extraordinary individual, perhaps sharing some traits with someone like Feynman, but is not aware of how far they deviate from the mean. Although this is the recipe for success with high performers, most people have less discipline and will implode.


You can't deliver the car until the last piece is bolted onto it.

There's only so much value in celebrating having the first half of the car put together. It still won't tell you when it's ready to ship. Especially if you've assembled it in the wrong order...


You can ship a car with an engine that goes 0-60 in 10 seconds. Then you can ship the next car with an engine that does it in 7. If you try to develop an exact thing by an exact date, you're bound to either ship something that's broken on the date, after a lot of heart-ache, or to ship something that works late, after a lot of heart-ache. Then, good luck getting your people to make the next product better. All the cards were played; all the bridges were burned; and you got a shitty product.

Instead: let's ship the best working car we can by <date>! And here's why that date. Who has ideas for how to get an even shittier completely working first-iteration done six months before that? Now, go figure it out and make it happen. I trust you. (To self: and I'll trust you even more as I see each shippable iteration that you enjoyed making.)


It also changes task to task and person to person. I'd very much consider myself a self-starter and self-motivated, but if I'm given a task that's mundane and carries no creative aspect then a one day task can take me a whole week.


Coming from the view that I agree with almost all the points he's making, I found it an incredibly bad article.

Half of it was a long tangent about NPD after which he flatly admits that his readers shouldn't be trying to diagnose NPD... but he's giving you detailed recommendations about how to recognize all the behaviors associated with it and then act on them! This is coming from a clinical psychologist, so that seems wrong.

I agree you want to identify people with that behavioral profile and get them out of your organization (whereupon they'll be Somebody Else's Problem...) but it seems like this psychology could be translated into guidance with less ethical sharp edges than "here's the DSM description of this disorder. But don't actually play psychologist, LOL!"

After that he finally gets to deadlines and kinda sorta gets into why they're bad. And I don't disagree, but the article claims that deadlines are used by emotionally immature managers acting out of "fear." Sometimes, but deadlines are way too commonly used in every sector of industry to attribute them to emotionally immature leaders.

It's off to a vignette about a manager who couldn't recognize his greatness. So after he's spent pages tell us about how narcissistic people behave, this section felt like he was trolling me to think he's a narcissist. (I don't think he's a narcissist, just full of himself; which may well be an accurate self-assessment.)

But the manager's problem wasn't deadlines, it was micro-management which manifests exactly as he describes. In micro-management deadlines are one of a number of symptoms, but the underlying problem is the fear and emotional immaturyity he mentioned earlier.

He finally does get to why deadlines are so common: "They are a form of contract that can enable multiple organizations to synchronize their efforts, organizations that might be in the same company or in different companies."

The need to synchronize between organizations is plainly why deadlines are extremely common.

That's my real criticism of the article: he's a clinical psychologist, a rather irresponsible one, and he's viewing this through that lens. While it's insightful in many ways, deadlines represent a structural problem more than a human problem and the article would be better if it didn't try to solve them. (And, in fairness, most of it doesn't even address them.)


I liked the article, but about a third of the way in I thought: "This article needs a good editor"

Rule number one of writing is to be willing to cut some good material out because it does not fit your current piece.


I'm not only trained as a clinical psychologist. I also have 14+ of experience as a professional engineer and a manager/leader, with an MS in electrical engineering. So I'm viewing this as someone who worked an individual contributor, a technical leader, and as a manager, and then went and trained as a clinical psychologist, and then came back to engineering. I also coach leaders.


The GP is suggesting that you add "reader, writer, and editor" to your credentials. Not that I give one single care about any of them.

The middle section could pretty much describe "anyone management doesn't like that doesn't completely give their life to the company". It equally applies to the sociopath as well as the talented person that isn't excited by your business plan of selling ever-more paperclips.


Any knowledge or skillset can be misunderstood and/or misapplied. I'm doing my best to express my understanding, which may, of course, be completely wrong. I've also been doing my best to understand this stuff, which included taking a long break from engineering work to study it.


Hard deadlines cause buggy and broken releases. No deadlines at all mean there is no goal to strive towards and projects can float around in limbo indefinitely (see: Valve Software).

Deadlines are necessary, but if you want a quality product you can't be a slave to them. If they have to move they have to move, but you still have a goal. If you have to move the deadlines too many times that is a sign you need to look at your project leadership. They are a highly valuable tool, just don't become a slave to the tool.


"Plans are meaningless. Planning is essential" -- Dwight Eisenhower


I don't know; I had no deadlines at the pretty successful biomedical device company I was at and was plenty motivated to work a lot of hours. Do y'all not have managers that ask what you've done for the week? I mean, that's what always pushed me to work very hard; I'd feel terrible if I had little to show for 40 hours of work.


Deadlines are a must IMHO to scale anything, they should be negotiated and adjustable (either by moving the deadline, taking on debt, or cutting scope), but are necessary.

Why? because theres more to a buisness then enginnering (and product). Sales, marketing, investor's, and other entities also deal with complex issues thwt require them to reliably understand the priority and timeline for products.

I've seen teams that follow "it's done when its done" and teams who work as a unit to hit on or very near deadlines. The latter is usually 2-4x+ more efficient and the former I have only seen work when the buisness was in a spot that it could go at least 6months without and product/enginnering output. I would flee from any startup that took the former approach.


Indeed. I think TFA is opposed to non-negotiable externally imposed deadlines, which is not really news.


I agree. But sometimes dates for delivery of something do need to be set. That approach should be very selectively used, with an understanding that it's not a demand that X is done by Y, but that something will be shipped on Y. Then, the question is how do we most effectively motivate people to make X as amazing as possible? On one project where I defined what X was (a unit on a chip), I delivered it by Y with all the most important features and zero bugs. Later, my manager (who I almost never interacted with) revealed that my productivity was equivalent to 32 engineers in a competing company.


I think that only tells us about you, not about most people. Most people do not find the path to that outcome.

Also, do you think your productivity was equivalent to 32 engineers? Regardless of what your manager said.


I always think I'm doing a shit job and not getting anywhere near enough done. However, I always seem to get rated as a top contributor (which surprises me). In this example, my manager told me that he had obtained information that a team of sixteen people had accomplished the same work as I had in twice the time. I believed him, even though it seemed insane, particularly given that I felt like I was doing a crap job. I don't see why he would lie to me about that.

Another example like this (from later) was when I designed a context-switchable HD MPEG-2 core with two other people. We had the CEO/CTO of a start-up come in to pitch their supposedly equivalent core to us. They had a company of dozens of people who had all been working on the project for a couple of years. We had been working on our project for six months and we were much further ahead in development than them.

It seems to me that the performance and quality bar is just really low in general. Execution is way lower than it could be. I can only imagine that it's a motivation problem.


I didn’t think he was lying, just wondering what your own assessment would be.

I think you’re right that motivation has a lot to do with it, but there are other factors too. Being 32x seems like too large a gap to be explained by motivation alone, unless the situation over there was extremely dire. We have to entertain the possibility that you’re also much better than they are. Attribution to motivation alone makes it sound like your mental model is based on the idea that intelligence and aptitude is equivalent in everbody.

I’ve always said to younger folks new to the workforce that the way to get above average performance reviews is to simply give a shit. That alone seems to put any minimally competent person ahead of half the competition.

And to what extent is the ability to maintain focus and motivation a talent on its own?

Edit: I just want to say, I found the article extremely enjoyable. I am a little bit surprised by some of the feedback in HN comments. I’ll be blunt, you sound like you are bragging and have an elevated sense of your own worth. I do not think that is actually the case, but your writing (or maybe just your accomplishments) seem to trigger that heuristic. In my estimation, you seem to just be presenting facts and laying it all out, and I’m not sure how to do that when those facts happen to be flattering. As a clinical psychologist, maybe you have insight into why someone perceived as bragging gets downvoted. Since you expressed an interest in writing and motivating people, you might want to think about how to present that information without it distracting the reader by triggering their insecurities (if in fact that is happening). I generally struggle with that as well - although not on this particular issue, because I do not really have any great accomplishments to brag about ;)

Although I like the article, my biggest issue with it is that I would like for it to be true, but I am unconvinced that it’s a recipe for success with most people. I’m not sure how many people you have managed, but have you really not seen anyone’s performance drop without deadlines?

You’re getting shit for going off topic, but I’m glad you did, because I would not have clicked on an article about narcissism.


Wow. Thank you. In hindsight, I think I did do an impressive amount of high-quality work. After getting a lot more experience, I realized that what I did was impressive, even though at the time, and for a while afterward, I felt that I was underperforming (even when I was repeatedly assessed as a top performer). This is a recurring pattern for me. For example, I often don't realize the true value of my articles until I read them much later, with a perspective as if I myself did not write them.

I have written a lot about the topics that you're covering, actually tons on it. I have written about motivation, success, and imposter syndrome, and I will continue to do so.

Yeah, some people seem to think I'm arrogant or bragging or "narcissistic," without apparently understanding what that really means. I have spent 16 years in therapy learning to give less of a shit about that stuff, to not take responsibility for other people's emotional reactions. I'm also trying to be as honest and truthful as possible in my articles. I do also enjoy being visible, and I like inspiring others to achieve their full potential.

And I agree: the skills that lead to amazing quality and volume of work are things like focus, conscientiousness, persistence, and self-awareness. I have written extensively about this. All of these attributes are learnable. I believe that anyone can achieve at very high levels compared with the current bar. I'm not special at all.


Correction: there was one small bug that was hard to avoid but relatively easy to fix. And in terms of interaction with my manager: I did send him a weekly report on what I had done each week. But he trusted me too much, or was way too busy, to interfere.


> I've seen teams that follow "it's done when its done" and teams who work as a unit to hit on or very near deadlines.

There is room between these 2 extremes. A team that follows KPIs or some kind of agile process, for example.


"So the rocket launch is planned for October, will the software be ready?"

"Not sure, the software developer team doesn't like deadlines, they'll be finished when they feel like it."


I'd make a related argument:

When people are producers they don't like deadlines but as soon as they are consumers they demand them.

Go build a house and you'll be constantly asking "when will it be done" and "whenever" isn't acceptable to you.

Order something from Amazon and "it'll arrive whenever it arrives" isn't acceptable to you.

Sell some stocks and ask your broker when you'll get the cash and "whenever, in a few days, not sure man, asking me about dates really takes me out of my Flow State" doesn't sound so great.

We want deadlines. We want to know when our iPhone will be repaired, when our drycleaning will be done, when our children's schooling will be done for the day, when our plane will take off, when our car repair will be done, when the movie will start, and so on.

I always find that these kinds of articles can too often come across as "deadlines for you, but not for me" if they don't really grapple with that reality and try to come up with explanations for the dichotomy.


In addition to this, to narrow the scope strictly within software engineering, I don't think too many people on HN would sign an employment contract that states that cash will be paid or equity vested "whenever".

So why the hate for deadlines? Software engineering does not exist in vacuum separated from business constraints like runway or annual budgets. To demand deadlines of your employer but to not be willing to even try to meet deadlines in deliverables seems to me to be a bit unprofessional and disconnected from the underlying business reality. A whole company that wants to shrug off this underlying business reality seems even worse. A series B startup that doesn't meet deadlines might not even be in business in 6 months.


If you understand a software task well enough to profile, optimize, and make correct predictions about it (the way UPS does with package delivery, or Lennar with exurb manufacturing), you understand it well enough to build a reusable solution. If you have good architecture and code reuse, the share of time that a team spends on well-understood tasks with accurate estimates should approach zero. Software scales - that's the point.


This response strikes me as a typical "software development is so special we have to live by different rules" response that developers all too frequently make. Software development is not as special we often make it out to be.

Building a house is the same, yet we want our builder to tell us deadlines and get upset when he misses them.

All infrastructure work is the same, yet we gleefully complain about how that subway/overpass/bridge/new airport is behind schedule.

Medicine is the same, but we become (extremely!) upset when our doctor is 60 minutes late to our appointment and we have to wait.

Teaching is the same, but we'd flip out if our teacher decided to keep kids an extra 20 minutes and we're waiting outside in our car to pick them up.

Heck, just look at how upset people get about how long it takes George R.R. Martin or Patrick Rothfuss to write their next books!

I guarantee many of the same people complaining about George R.R. Martin taking so long also complain about their boss asking for estimates and setting deadlines.

And on and on and on.


People can want estimates and deadlines, but the estimates won’t be correct and the deadlines won’t be met for an ambitious custom build house, a subway tunnel through unknown “legacy,” or a diagnosis and treatment of an exotic disease, because that’s not how it works.

They might be correct for overpass #10,000, build #300 of Standard House Model B, or churning out antibiotic prescriptions. But those projects should cease to require much if any engineering support, leaving only the ones with more unknowns.

Subway tunneling is a really great example. You run into underground infrastructure that wasn’t in the documentation and you have to stop and figure out whether it’s still used, what it’s connected to, etc. and either refactor it out of your way or change your own route before continuing. You don’t know in advance how many such situations you’ll run into or how difficult they’ll be to untangle. So subway projects are chronically late and over budget.


Building houses is an excellent example. When a large corporation is building an estate, the time and cost taken to build the houses is fairly well known, and consistently accurate (to a degree).

Custom/self builds are famously hard to predict, and nearly always go massively over budget and over time (twice as long, twice as much is more common than on budget, on schedule). Often because there are significant changes to the requirements as the project goes on, because the customer changes their mind, or because unexpected things are discovered during the build.

In fact, with the arguable exception of teaching, which is a classic example of deliver to deadline with no specific set of features, all of your examples are things that people are unable to accurately predict.


"So, will the rocket control software be ready by October?"

"Yes, it will. But we can't guarantee it will work correctly."

Choose your poison.


Hmm, this doesn't seem like a good argument. Would you really rush that kind of thing if the developer team was not feeling good about the state of the software? Not always, but sometimes failure can be much worse than late.


What fraction of developers work on rockets versus A/B testing signup button colors?


"So the marketing for our new product has to be purchased 3 months in advance to tie in for the TV ads, magazine ads, bus stop ads, and web buys. Not to mention we need to work with legal, and our CEO needs to talk to the board. When the devs be done?"


In 3-5 weeks (change to months for a bigger project). Don’t buy the ad until it’s in production. Use the 3 months to iron out tha bugs that will be found in production.


Is there some rule that the product has to be available for sale and advertised as soon as the code rolls off the production line? Why can't they begin scheduling these things when the code is 90%+ done? It's not going to rust or go stale while marketing gears up, having a completely different business unit driving you're release process is just a recipe for releasing buggy shit.


If you're developing something novel and it's not deployed as it's completed you risk a competitor beating you to market. As well as this, the time between having a product or feature complete and ready for release equates to lost revenue. The ideal is to have all aspects of the project completed and ready for deployment (actual feature, supporting documentation, training materials, marketing campaigns and materials, etc.) at the same time to maximise possible revenue.


> If you're developing something novel and it's not deployed as it's completed you risk a competitor beating you to market.

If you're competitor is imminently releasing a competing product then what you're working on isn't really novel. It would also be potentially patentable if it really was novel, which would grant you a monopoly on the space.

> As well as this, the time between having a product or feature complete and ready for release equates to lost revenue.

What's the lost revenue from releasing a buggy product? What's the lost revenue if your competitors are about to release a working one? What's the lost revenue from your developers jumping ship and all the related turn over costs? Some of those mistakes could sink the product/business entirely.

> to maximise possible revenue.

You agree that maximizing revenue at the expense of everything else isn't the goal don't you? If that's all that mattered then development would be outsourced to a third world country to save on expenses. But we've mostly learned no to do that because despite promising revenue gains they lead to several bad outcomes in the short and long term, pushing hard deadlines is no different.


Most of us are not writing space shuttle code (or any other aerospace code, considering all space shuttles have been retired).


Changed to rocket.

Most of us aren't writing code that will go to space, but most of us work with other parts of the business, and marketing, management, investors need agreed deadlines to coordinate with.


No, but the bootloader will be! We can just send up the final image once the satellite is in space.


I think that's how NASA develops their longer-range probes, like Cassini and New Horizons. It's something like a six year journey to Saturn, so plenty of development time after the launch.

But that bootloader had better be flawless!


"a^n + b^n = c^n, can you prove this by October ?"


> Agile contracts, whether negotiated one-off project contracts, or regular-cadence release schedules, extract the value of deadlines but leave behind the toxicity.

So, basically arguing for flexible deadlines, which totally makes sense.

But if your product or service is tied to an inflexible deadline like an event, you'll probably need to manage with strict deadlines to uphold your end of the contract in time.


This is true, but those events are few and far between in most cases, and usually publicizing far in advance is a mistake when the work is not at some late stage of development.

I think this was probably one of the better articles I've read about leadership; but then, it confirms most of what I believe.


The book "It doesn't have to be crazy at work" [1] presents a nice approach to deal with deadlines:

> [...] The date won’t move up and the date won’t move back. What’s variable is the scope of the problem—the work itself. But only on the downside. You can’t fix a deadline and then add more work to it. That’s not fair. Our projects can only get smaller over time, not larger. As we progress, we separate the must-haves from the nice-to-haves and toss out the nonessentials [...]

[1] https://basecamp.com/books/calm


Ok, so the boundaries and perspectives of the article are a bit unclear because so many intersections are mentioned.

I need to step back and resort for a better comment on this.

I understand the flow of the article, but any 3 lines i would like to create a comment.

I think it's a good article by itsself, but it takes time to reflect on it and give ordered, umderstandable comments on.


Two things I've learned about deadlines #1 - never get into a fight with a superior about a deadline - think of the princess bride quote about land wars in asia.

Which brings us to #2 : look at them relative to what's important to your business. Much of the time a deadline isn't really a deadline at all - its a point in time to show progress in the right direction. With that in mind, i might say to the team - "what's important to this business is _______ , so lets be sure to highlight our progress on items a/b/c because they're key to ______. ..all this other shit in the backlog is #2 .. n that Alice and Bob want. Alice and Bob will get their shit when we get the important shit done (which might be never) [0]

What direction is important to the business? Well, hopefully the direction of solving a problem or delivering a widget to someone who is waiting to actually use it and hand over $ in exchange. If its something else its often your deadline playing chicken with someone else's deadline on the gantt chart and then its the old joke about two guys running away from a bear.

[0] Alice and Bob will get their shit when they start contributing items to the backlog that are aligned with what is important with the business.

EDIT: deadlines aren't inherently "bad" - especially when one is competing against others for something. The problem is too many points in time are made to look like deadlines and often by the wrong people. Imagine running a marathon, and someone is yelling at you from the sidelines : "run as fast as you can to the 4 mile mark!"


I am the author of the article.

To those commenters who write that deadlines are necessary because many, or most, employees are not motivated self-starters, I posit that this is a symptom of poor leadership, originally by their parents.

Yes, it's possible to force people who don't want to do things by using fear and control, but it's much more effective to use what we know about human nature to generate a 10x output that is sustainable and actually enjoyable.

Ineffective leadership is not an optimal solution for ineffective leadership. It's a downward spiral.

This reminds me of the people who spank their kids because they're disrespectful, but, as we know from research, spanking kids makes them disrespectful. Spanking kids just makes them pretend to be respectful while being increasingly disrespectful.


I've never seen good results from coercion (such as threats, bribery, or punishment) in a workplace, and I'm suspicious of rewards, which seem like another form of bribery. Deception also seems deadly.

As you point out, autonomy, mastery and meaning are motivating, and their absence de-motivating. Coercion undermines autonomy.

It also seems that people's work suffers greatly when they are unhappy, stressed, fearful, overloaded, or fatigued.


Yeah, I think that there is a deep cultural bias against actually digging in and looking at human problems, like work, from a human-centric perspective. There's a presupposition that most people hold that management is about control. This is why we draw org-charts top-down. In my view, management is about support. I prefer to draw org-charts bottom-up. The CEO is at the bottom. The whole structure is there to support the effort of those at the tips of the branches, the individual contributors.


There are many scenarios I could posit, but I'll pick one. Let's say your pre-revenue start-up needs a product for sale within 4 months, because that's your company's runway. There's a lot of work to do and limited resources, but if you don't meet that deadline your company has no product to sell and you are out of a job. Are you really arguing that it's poor leadership to say: "we have a hard deadline- the product must be ready in 4 months"?

There are many such hard deadlines in life, and failing to recognize them and motivate your team to meet them is poor leadership.


It's just a date. Ship something by this date. I would suggest shipping more than once before this date. I would not call that a deadline in the normal sense that it's used. Of course, dates should be used as part of the planning process, when necessary. The problem is that most deadlines are overly restrictive and used unnecessarily only to reduce the anxiety of the manager at the expense of the team's motivation. So the net result is less, delivered later.


There's an interesting video by Allen Holub that I've seen on the somewhat related topic of ridding software development of estimates (#NoEstimates)[1].

He argues that they're responsible for deadlines that are impossible to meet due to them being based completely on a guess. He then goes on to talk about how we can still get predictive power without giving estimates. I found it extremely interesting and highly recommend it.

[1] https://www.youtube.com/watch?time_continue=4&v=QVBlnCTu9Ms


As Eisenhower says "Plans are worthless, but planning is everything".

Setting deadlines is useful for planning. Respecting them at all costs is dangerous. They need to be updated when we have more information.


The deadlines absolutely have to have some amount of padding in them.

Often the problem with missed deadlines is the inexperienced "managers" that set them.

They have no idea how long things take and as a result introduce wrong time estimates that lack proper padding. This often jeopardizes the whole project and causes unnecessary amount of stress.


I don't feel like you can always wave deadlines away. There's always events like conferences, big customers on the hook for a sale, end of quarter, etc. I'd settle for reasonable discussions about scope trade-offs, resources, etc.


Due Date = Real deadline (like your examples)

Target Date = A guess as to when something will be ready that can and will change with new information

Sprint = Not even remotely a deadline, just a measure of time that serves no useful purpose at all outside of contract dev shops who sell time by the sprint


A Sprint simply defines a planning cadence. Some teams find it helpful to do planning and retrospectives on a fixed schedule to ensure they actually get done rather than postponed.


Sometimes the purpose of a sprint is to have a synchronization point that allows you to evaluate the state of the system in some way.


The title of the article sounds far more controversial than its content. The article in a nutshell: waterfall is bad, agile is good. Click-bait anyone?


... plus nearly everything else I know about leadership.


Deadlines = tradeoffs

Unnecessary deadlines = unnecessary tradeoffs.


tldr; a rambling article about narcissism (ironically)


Narcissistic employees are one of the main causes of loss of employee motivation. Deadlines are a highly ineffective mechanism that attempts, unsuccessfully, to motivate employees (by controlling them with fear).


Well, this was mostly a very long rant. This guy seems to be full of frustration. Also the intercept about narcissists? WTF? That was completely beside the point.

I would summarize it like this: this guy have a lot of anecdotes to tell and now he is projecting his prejudice and sour experience to everything and everyone.


In case you missed it, the number one thing I know about leadership is: root-out and fire narcissists. It's the most effective thing you can do to turbocharge your company.

FYI, one of the ways you can spot a narcissist is by how they project their emotions onto others, rather than taking responsibility for them.


The narcissist part was interesting. But it seemed completely unrelated to the topic of the article I clicked on, namely, deadlines. I recommend splitting it into its own blog article.


Great idea. I'm also wondering if this was actually an article about narcissism very poorly disguised as an article about deadlines.


First: I didn't read the article - but the headline.

I'm not sure if i hit the tone, but without deadlines the culture to ship any things on time and to expectation would vanish.

Shippable would become inforeign and obsolete, and the least distance to bodily happiness would be commonsense. Ship it, till you break it.

Ship bad code wizh vi4cular recursions neverless: cannabis

Ship dead code dancing forever neverless: opiates

Ship the fuck up coz it is colorful: lsd

(Maybe I should not press enter to send, but, i will do now) And then i read the article and try matching it to the headline.


Am I having a stroke


Thanks for a hearty chuckle! Still laughing!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: