Slashdot Mirror
Arbitrary Deadlines Are the Enemy of Creativity, According to Harvard Research (qz.com)
Time can feel like the enemy to an employee in any role, and in any industry, but it's most acutely threatening to creative types. From a report: We may tease them for their diva-like behaviors when they feel persecuted by a deadline, but we have to admit that "develop an amazing new idea" is not something that slides into your schedule, like pick up lunch or respond to new clients. Nor can systems be tweaked and extra hands hired to help hit a goal that requires innovation, the way they can when mundane busy work is piling up. And yet deadlines are a fact of life for any company that wants to stay competitive. In a recent Harvard Business School podcast, professor Teresa Amabile, whose academic career has focused on individuals, teams, and creativity, offers some guidance for managers who struggle to support or coax their creative talent. She explains that although the creative process itself can't be controlled, certain structures can set up the conditions to move it along. When possible, managers should avoid tight deadlines for creative projects. In her work, Amabile found that creative teams can produce ideas on a deadline, and creative people may feel productive on high-pressured days, but their ideas won't be inspired.
Curse these deadlines!
Rumination is free labor. If I'm thinking about a project for several weeks when I'm in the shower, trying to sleep, driving - that's extra overtime for free.
Doing all of my thinking on a tight deadline while also doing the actual design or coding involves a lot of bad guessing. But there comes a point where I could just think about all the possibilities forever and never start or get anything done.
But the boss sez: ``I don't care if their ideas are inspired. They'll be on time and that all I--and my boss--care about!''
Systemd and Gnome 3. These would have been much better if the deadline was around 2075.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
What's next? We'll discover that noisy open office bullpens aren't conducive to any sort of work that requires concentration? Or will we discover that most managers don't much care about productivity as long as they maintain the illusion of control?
Proud neuron in the Slashdot hivemind since 2002.
All I need are some tasty waves, a cool buzz, and I'm fine.
wanting to quantify everything based on cost and time...
No wonder they are the death of many companies who continue to survive financially, but never produce any creative products after they get 'monetized'
One can't rush creativity...it must be inspired...and not with money.
...what's arbitrary? The average creative would love infinite time, but reality is that there needs to be a line drawn at the start, and all efforts made to complete within that time amount.
The second biggest enemy of creativity is probably the lack of any deadlines. With no urgency, the creative project is put aside for more immediately pressing tasks (or distractions).
It's good only for brain storming part, which is the very beginning After that you just apply due process.
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
if you don't have a deadline. What's the compromise?
Seriously, I've noticed that after working just over twenty years managing programmers and a few product people that things get done when you schedule a spec review or a demo.
Most deadlines are not arbitrary. They have some relation to the real world. There may be an external forcing function, or it may be a time=money calculation.
Winds of Winter.
More ascetic bullshit predictably like clockwork.
Few organizations operate in a vacuum where they can take whatever time they want to develop new ideas. Generally there is competition in some form and things are advancing. A brilliant idea today may be worthless a year from now when someone else has developed it.
In addition to competition, there are sometimes specific deadlines - external project reviews, shoot-outs between competing projects, competitive bids etc that have externally set deadlines. In response to those if often makes sense for managers to set a series of smaller deadlines to try to keep a project on schedule.
I think a good manager will make sure that their employees understand *why* a deadline exists so that the deadlines don't seem arbitrary, but I think its almost impossible to avoid having deadlines.
We never achieve them anyway. It normally starts out as, "We need to deliver a high quality product with A,B,C,D,E,F,G,H by the deadline."
Then it goes:
But we can't do D due to a defect in the vendors/open source project's libraries.
The deadline is slipping so we talked the customer into deferring the release of E until the next release.
Oops C relies on D so we can't ship that.
Chris and Bob quit so we are even more short handed than before.
G is experiencing massive scope creep, let's cut capabilities so we can ship it.
We're more short handed than ever so we can't fix more than critical bugs.
The QA automation is falling behind due to all the changes so we'll have to test manually.
So what get's shipped often looks nothing like what was promised. All that happens is the goal post is moved and victory is declared.
putting the 'B' in LGBTQ+
Most programming isn't creative anymore. Most of what we make is some version of a workflow app, where the organization of the code follows the organization of the UI. There are slightly interesting problems around scaling, but most of those are solved too, unless you are Google or Amazon.
"First they came for the slanderers and i said nothing."
Since every slashdotter is a middle-aged unemployed former tech worker, there are no deadlines to impede creativity among the washed-up has-beens.
I'm willing to bet that arbitrary creativity is also the enemy of deadlines. Depends on your priorities, I guess... Sometimes constraints produce miracles (and vice versa).
A looming hard deadline can do quite a bit for creativity - ask any writer. Given enough time, GENERALLY, you can create a better solution or work but this can also be a hindrance.
For proof I submit - Star Citizen.
Deadlines are a very useful means of persuading people to work extra hours for free.
When you are dealing with a situation with other folks depending on you, then the timetable may matter moreso than how creative it can be.
However novel new capabilities are not generally well served by making up a deadline if one does not naturally exist.
However that later situation drives managers/project managers insane. Why even bother trying if you don't know when you would finish, how can you 'grade' yourself if you don't know when you would deliver, so make up something.
Having a backlog of ideas without a milestone to make them due is a fine thing, but project management *must* have it on a roadmap or else get pissed.
XML is like violence. If it doesn't solve the problem, use more.
Even God has deadlines. If He let his deliverables slip on days 1-5, you wouldn't be here.
The problem with having no deadlines is that too often nothing gets done. Look at Valve for an example of what happens when management is too hands off. Half Life 2 Episode 3 is a full decade behind schedule now. I get that you can't rush greatness, but you gotta keep it motivated.
I read the internet for the articles.
Arbitrary means the EXACT OPPOSITE of necessary.
Like writing a new screenplay. Most writers are working as baristas in Los Angeles, still plugging away at their first salable script. If you want a real 'creative' job, you've got to handle the consequences of your writer's block on your own.
Have gnu, will travel.
Arbitrary Deadlines Are the Enemy of Creativity
So are no deadlines.
Perhaps it really depends on what you're trying to do. I've actually done some of the most creative problem solving with a deadline looming because it forced me to -- and I hate myself for saying this -- think outside the box. This type of thing is usually different than "develop[ing] an amazing new idea", but not always. In any case, to state what should be obvious, deadlines can be a help or hindrance depending on the task and person.
It must have been something you assimilated. . . .
Problem A: think of a cool name.
Problem B: think of a cool name for a starship.
Which of the above two problems is easier and which is harder? If you solved both problems, which name was cooler?
My guess is that problem B was the easier one and it's also the one where you came up with the cooler name. Why? Because it had a constraint, and perversely, constraints cause creativity. Or so I've thought.
Problem C: think of a cool name for a starship, within 30 seconds.
I added another constraint, so you got even more creative, right? No. Something about time as a constraint is .. odd.
But wait a minute. Let's say I show you a mid-game chessboard, and it's white's turn. In one scenario, I give you lots of time to try to come up with the best move. In another, I give you only 10 seconds, and then you must make a move.
Which chess move to do expect to be the most interesting? Note, I didn't say the best, just the most interesting. I think maybe the time-constrained solution might come out on top.
Is this all bullshit, or is there something interesting about time?
Neil DeGrasse Tyson mentioned [paraphrasing] many people say they are very productive such as answering all these emails, gathering information, making work orders, etc. The question is did you create something new?
mfwright@batnet.com
I'm going to butt rape you now!!!
Ah geeze I'm sorry, I got nervous being the first response! AH GEEZE (pulls down pants).
"Teresa Amabile, a creativity researcher at Harvard Business School, and other researchers collected more than 9,000 workday diary entries, crunched the numbers and were able to isolate the two factors that promote creativity on a deadline:
Time to concentrate with zero interruptions.
Knowing why the problem is important to solve."
https://www.success.com/blog/how-to-inspire-creativity-on-a-deadline also out of Harvard.
Once I asked an application owner what was driving the absurdly short timeline and he replied with a straight face that it was when his yearly review was to occur.
love is just extroverted narcissism
I can't help but suspect at least some of the problems the professor has observed are the result of creative people feeling abused and undervalued. I know from first-hand experience there's times when an arbitrary deadline can inspire creativity.
How many times have you had a project dropped in your lap with an impossible deadline...again...and you know the only reason is because some committee well up the food chain has been having a month-long stroke fest over how credit will be meted out?
The best, most productive creative work I've done has generally happened when something comes up without warning, and we're asked to please, please, please deal with it.
I've calculated my velocity with such exquisite precision that I have no idea where I am.
The problem I have with arbitrary deadlines isn't really the date, although those can be unrealistic. It's the never-ending nagging of project managers. Anything that prevents them from checking the box they need to check or moving the date out on their Gantt chart is an immediate emergency that must be addressed by endless status meetings. The endless status meetings make the project later by tying people up discussing strategies to reduce the time something will take.
I think part of it is that PMs have been taught that, just like MBAs, they can project-manage anything. And I can see their methods when they make $100K+ and their sole job is to check those boxes, or nag nag nag until they are. But creative work on any complex project isn't like drywalling a commercial building. There are some things you can't rigidly schedule, but software development is treated exactly like a construction project.
I have noticed that the best project managers don't nag -- they're often the ones who've actually done the work before and aren't looking to throw you under the bus. The worst are the PMP clones. I seriously have had a couple PMs who are following the PMBOK line by line, using the PMI-approved terminology, and PMI-approved nagging/threatening techniques. That's the kind of PM you don't want.
Comment removed based on user account deletion
My understanding is that creativity is like tree sap. You can tap into it periodically, draining it, but you can't do anything to speed up its production.
Corruption is convincing someone that the selfless ideal is the same as their selfish ideal.
A different approach is to allow time BETWEEN projects to ponder and discuss problems and bottlenecks in the prior project. The stacks and shop conventions should be tuned so one doesn't waste time on stupid shit for the next project.
You need fast turn-around to survive in a competitive world, but to get that you need tools & practices that do what you need without giving you headaches you don't need.
Table-ized A.I.
I was a scientific researcher and later I was an engineer. It's great to stare out the window and ruminate, and many good ideas are germinated that way. But, nothing is accomplished without the pressure of some kind of deadline. And, there is a big difference between formulating a new theory and actually executing the development of something.
One Silicon Valley CEO always asked candidates if they thought having great ideas or having great execution skills was the most important. He was adamant that execution was more important -- even with a mediocre idea, you can produce something. That's better than having a lot of great ideas that are never realized.
"Thru the mystic arts we harness energy & shape reality - We travel great distances in an instant"
* Making the web FASTER
"The Avengers protect the world from physical dangers - we safeguard it against more mystical threats"
* Making the web SAFER
(vs. inefficient remote DNS/Antivirus (riddled w/ security issues) or browser addons (sold out to not work by default ala adblock) for more security/speed/reliability via what you have natively vs. illogically "Bolting on 'MoAr'" w/ hosts doing more for less)
APK
P.S.=> "How do I get from here to there?"
THIS:
APK Hosts File Engine 10++ SR-1 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/
ALL quotes from the film Dr. "StRaNgE" https://www.youtube.com/watch?feature=player_detailpage&v=kNdM7b1Lm04#t=31/ for "FULL EFFECT" of what inspired me (I read the original 1960's comic as a boy)... apk
Deadlines are a fact of life in the corporate world. A good manager will have a phased plan that delivers a minimal product that will be enough to meet a given deadline - this minimal product is not expected to have much creativity or innovation. However, future plans should allocate a portion of the engineer's time to improve the product without the strict deadlines or even goals over an extended period, say 10% of their time (i.e. half a day per week) for as long as the product is supported.
Most engineers don't have any problems doing this - be it to simply refactor/cleanup code, find more efficient algorithms, and once in a while they might surprise everyone with an innovative addition. The more important aspect of this improvement phase is the process in which the engineer went about the task. E.g. an engineer discovers at the end of the exercise that they were not able to improve on scalability of the existing product, is in itself useful, because they managed to demonstate that the existing implemention is actually scalable. Some times they will encounter a problem or an improvement effort that will take more of their time or assistance from several other team members - this is usually a good thing.
Face it. Some of the creative types are such procrastinators they wont do anything unless there is a deadline.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Yeah, I have a sort of theory of project management that dictates that deadlines can't be taken in isolation. They're actually a part of a triumvirate of priorities: the deadline, the budget, and the required deliverables.
When you're starting a project, you should have a deadline, a budget, and a list of what is to be delivered. However, you should expect by default that not all of them will be met. So then you have to know, which ones can you sacrifice, and how much can you sacrifice them?
For example, let's say you discover that you're not going to be able to meet your deadline. Really, that's not the right way to think about it, in terms of "not meeting your deadline". You might possibly be able to meet your deadline if you throw more resources at it (expand your budget). You can certainly meet your deadline if you cut back on your deliverables (i.e. just deliver whatever you have). So given those options, would you prefer to go over budget to make the deadline, make the deadline by shipping whatever you have, or not deliver on the deadline?
And there's not a real "correct answer". It depends on the project. Sometimes you can't sacrifice one to meet the others. Often, a project will require that you break all three: You'll go over budget, past the deadline, and you won't meet your design specs. However, you have to decide how much you can break which ones. For any project, there's some dollar amount budget that you just can't afford to go over, and some deadline that you can't go past.
The whole thing is way more complicated than what I'm portraying here, but my basic concept here is in line with the quote, "No plan survives first contact with the enemy." You should have a plan with a deadline, budget, and deliverables, but understand that things aren't going to go according to plan. The real question is, when things go sideways, what are you willing to settle for? What parts of the plan are you willing to give up? In some ways, the answer to that question is more important than the actual plan you came up with in the first place.
It's a fine line with a steep drop filled with mixed metaphors on each side. I think the issue here hinges on the word "arbitrary" and in who's eyes?
I manage a group of programmers in an R&D environment. We routinely drive professional project manager types crazy because R&D means that, at some level, we really don't know what we are doing or how long it will take because we haven't done that particular thing before. On the other hand, we DO know what we are doing because, whatever it is that we are doing, we've been doing it successfully for some time. So, internally to the group we make realistic deadlines for ourselves and map them onto what the project managers want to know. Still, there are often the cases where we get 90% of the way through a project and realise that there is a much better way of doing it. This can be for many reasons, "the penny finally drops" and the programmer realises what they are doing, someone hears something at a conference or workshop, or a new feature emerges in a programming language or library.
Face it. Some of the creative types are such procrastinators they wont do anything unless there is a deadline.
That is exactly how it works. "Give us something we can work on by the end of the week." makes for a lot more creativity than "Meh, whenever"
If no management guidelines are offered, the creative types need to start coming up with restrictions they have to work in themselves, or else they falter
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Doesn't it really depend on your definition of "arbitrary"?
I mean, who really insists on entirely arbitrary deadlines? That you have to have something done by Thursday, when in fact it's not really due until 2025?
Sometimes, shit just needs to get done no matter how much "a few more days" might spur some purported pending creativity.
-Styopa
For most people in creative positions, time and money are interchangeable. Often it's not easy to see how that exchange works, but it's usually there.
You generally have as much time as there is money to support you until further investment isn't justified.
The flip is when you're working for yourself. In that situation you have as much time as you want, but you will receive no money until you've come up with something of value to someone else.
All the project management, management, reviews, and other similar stuff is just there to figure out exactly how to optimize and clarify this trade off (for other people, not for you).
See, the deadline for first post is not actually arbitrary.
Yep.
For the tl;dr folks...Good, Fast, Cheap...pick any two.
His ignorance covered the whole earth like a blanket, and there was hardly a hole in it anywhere. - Mark Twain
But what offends me is the lie, "We made the deadline". No, no you didn't. You fudged the situation and pretended that you achieved something. When you didn't. Which allows arbitrary deadlines to exist without onus or learning what worked. Very unscientific.
Do you get it? Instead of saying "We failed" and then looking for reasons continued failure is ensured and no improvement occurs.
putting the 'B' in LGBTQ+
Almost a perfect posting, and I definitely retain the 'Enemy contact' quote :-D
May I just add : you also should have, within your plan, some *margin* on all three features : a couple of weeks hidden margin that you'll carefully release in front of trouble, some extra work capacity ('money') for the like, and -as you mention- an idea of which feature Z you can remove if need be.
Margin management is key, while in general poorly done or underprovisioned...
I for one work in a big company where these three margins are perfecly mandatory, everywhere -but also almost always too small.
Even worse, many brilliant managers when facing this constraint do turn innovative (after all this is the story topic here ;-), but the only possible innovation there consists in finding tricks to fool the 'margin controllers' : like, there is obviously too little margin provisioned for delay contractual penalties, but it is because we expect our subcontractors to share that risk (...we just didn't finalize that negotiation with them)
Herve S.
And this is why Scrum was invented.
For all its faults (and there are many), what you describe is precisely the scenario in which it can turn a complete fiasco into a productive process.
I understand that, but I would say that, in that sense, almost every project will "fail". Even if everyone does everything right, it's rare that a project will deliver everything it set out to, on time and within budget. It's not even really the fault of the person who developed the plan or managed the project, but just the fact that things rarely go according to plan. The only way to make sure you don't "fail" is to set meager goals to achieve within extremely unambitious deadlines and over-inflated budget.
In that context, I don't think that it's necessarily good to think of it as "failure". If you have a long list of deliverables and you cut a bunch to meet a deadline, but the deadline matters and you get the features you actually need, that's at least a partial success. Maybe it's a total success, if the requirements you started out with had a bunch of unnecessary and unrealistic fluff. Or if you miss an arbitrary deadline that didn't really matter and produce all your deliverables shortly after, that could be a total success too.
Not all deadlines, deliverables, and budgets are created equal. The way I see it is, part of being a good project manager is assessing which things really matter, and then prioritizing those things. If the deadline is extremely important and you get all the deliverables you really needed by that deadline, then yes, you "made the deadline" even if you didn't produce every aspirational deliverable you set out to produce. Don't let the perfect be the enemy of the good.
Yes, I agree that your plan should have wiggle room. I think that's what you mean. I've always padded my estimates for timelines and budgets, and I try to underplay what I expect to be able to deliver. Not to be dishonest or get away with anything, but more like operating on the Scotty Principle.(definition, source, source)
But basically, I'll take the amount of time that I think something will take. Then I double it. Then I pad it some more. And then, even then, I expect that I'm not actually going to meet my deadline. I run the whole project on the expectation that things will go far worse then expected, even when I'm planning for everything to go wrong, and then I plan ahead for what sacrifices I can live with.
One of the glib ways I've described my whole process is, "I don't make plans. I make contingency plans." That is, I don't spend too much time trying to figure out how things will work if everything goes according to plan. I put my effort into figuring out all the various ways things could go wrong, what I should prioritize in case of a disaster, and various ways I can delivery my highest priorities in the worst-case scenario. Over the years, I've found that it's a much more effective way to think about projects.
Q) Why hasn't this project been completed to deadline?
A) Because you pulled the deadline out of your ass, without considering the amount or complexity of work required to deliver, ignored feedback that the deadline was unreasonable and inserted more tasks after the project started.
Requiem for the American Dream
You have a sort of theory?
You did not invent the triangle of time, resources, and scope.
Poser.
No one posted they love the sound of deadlines as it whooshes by?
I demand my /. of the aughts back.
I do get your point. But part of the problem is that there doesn't seem, at least in my experience, any provision made for slippage. Every release and/or sprint is filled to the bursting point with features. In disciplines like Operations Research the rule is to never fill the work queue greater than 75% [1]. Otherwise if anything goes wrong you're hosed. Managers want maximum productivity but the only only way to get that is through scheduling in extra capacity. which to most managers seems inefficient, so they cram in more work and ensure failure.
And I do believe we should label things as failures. By not doing so we come to think all things went well and we don't have to think about what we are doing. While a failure would cause an analysis of what went wrong and what needs to be fixed.
[1] Which is about the effective saturation point in ethernet.
putting the 'B' in LGBTQ+
Well again, I think I still wouldn't call it a failure just because the deadline is missed. I think you can label it a failure if the outcome is bad. If you're talking specifically about software development, if the release is a buggy piece of crap, that's a failure.
So if your manager sets the goal to implement a bunch of new features by a certain arbitrary, but they instead implement those feature later than that deadline, and then it's all good and everything works great, that doesn't seem like a failure to me. If, instead, they drop some of the proposed features for that release, but still release a substantial high-quality update by the deadline, that also doesn't seem like a failure to me. Sometimes you might include some aspirational goals that you don't expect to reach anyway, but as long as you get done the things that actually need to get done, by the time they need to get done, that's a success.
However, if management insists on reaching arbitrary goals by arbitrary deadlines, and the result is a bunch of overworked developers pushing out buggy updates with crappy half-finished features, then that's a failure. That's bad management.
In disciplines like Operations Research the rule is to never fill the work queue greater than 75% [1]. Otherwise if anything goes wrong you're hosed.
I guess my point here would be, if you fill it to 100%, or even 120%, but everything is properly prioritized and you're ok with only that 75% getting completed, then what's the difference?
I might give someone 20 tasks to do before a set deadline with the understanding that they'll only complete around 7 of them. Why? Because I could be wrong. Maybe he can do 10. Or 15. There's no reason for anyone to run out of things to do. I could be wrong in the other direction, and he only completes 5. The important thing is to prioritize, and to know which tasks actually have to be completed. It might be that we really only need those 5 tasks completed before the deadline and we're fine. Or it could be that we needed him to complete 6 tasks, in which case, we'll have to push the deadline back. And that might be fine as long as that deadline is arbitrary. It's still not a failure, and doesn't necessarily need an analysis of what went wrong, because nothing really went wrong.
If I'm giving 20 tasks and a deadline that only allows 7 tasks to be completed, and I still expect all 20 to be complete, that's when there's a problem. If only 7 tasks got completed when you really needed 20 by the deadline, and the deadline wasn't arbitrary, then that's a failure that requires analysis.