
Deadlines Are Killing Us, and Almost Everything Else I Know About Leadership - Elof
https://medium.com/@duncanr/deadlines-are-killing-us-and-almost-everything-else-i-know-about-leadership-7032a5fb12ac
======
tokyodude
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.

~~~
quickthrower2
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.

~~~
kybernetikos
> 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.

~~~
philpem
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.

~~~
kybernetikos
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.

------
commandlinefan
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.

~~~
everdev
> 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.

~~~
munk-a
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.

------
WalterBright
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.

~~~
umvi
> 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!"

~~~
kristianc
> "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.

~~~
cgrealy
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.

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

------
ben509
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.)

~~~
duncanriach
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.

~~~
satokema
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.

~~~
duncanriach
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.

------
jandrese
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.

~~~
commandlinefan
"Plans are meaningless. Planning is essential" \-- Dwight Eisenhower

------
mharroun
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.

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

~~~
duncanriach
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.

~~~
lawnchair_larry
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.

~~~
duncanriach
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.

~~~
lawnchair_larry
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.

~~~
duncanriach
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.

------
rb808
"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."

~~~
freddie_mercury
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.

~~~
closeparen
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.

~~~
freddie_mercury
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.

~~~
closeparen
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.

------
everdev
> 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.

~~~
mratzloff
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.

------
hezag
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](https://basecamp.com/books/calm)

------
reneberlin
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.

------
andyidsinga
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!"

------
duncanriach
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.

~~~
musicale
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.

~~~
duncanriach
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.

------
Vinalin
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](https://www.youtube.com/watch?time_continue=4&v=QVBlnCTu9Ms)

------
Rexxar
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.

------
readhn
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.

------
tyingq
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.

~~~
brightball
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

~~~
nradov
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.

------
speedplane
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?

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

------
29athrowaway
Deadlines = tradeoffs

Unnecessary deadlines = unnecessary tradeoffs.

------
borvo
tldr; a rambling article about narcissism (ironically)

~~~
duncanriach
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).

------
fogetti
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.

~~~
duncanriach
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.

~~~
prewett
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.

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

------
reneberlin
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.

~~~
sebastos
Am I having a stroke

~~~
rficcaglia
Thanks for a hearty chuckle! Still laughing!

