Arbitrary Deadlines Are the Enemy of Creativity, According to Harvard Research (qz.com) 123
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.
Not enough time to make an insightful first post (Score:5, Funny)
Re: (Score:2)
See, the deadline for first post is not actually arbitrary.
Rumination (Score:5, Interesting)
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.
Re: (Score:3)
Re: (Score:2)
... but management don't care. they want it, and they wanted it last week.
Re:Rumination (Score:5, Interesting)
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.
Like most things, you aren't going to get good results if you don't have implementation teams you can trust to give realistic estimates. And management teams who listen to these estimates, while probably making slight adjustments based on past results (almost always adding time to the estimates).
I'm in a project right now where we were introduced to the project early October, sat down for a full day requirements gathering session mid-October, and gave estimates by the end of October. We estimated code completion in mid-January. They gave us a mid-December deadline. The product will now be complete at the end of January, after spending weeks in constant status meetings trying to hit that ridiculous deadline.
In the end the only thing that changed from the results we promised in our first estimates is now the team's two architect-level resources are prepping our resumes just in case this type of shit doesn't happen again and/or this year's bonus isn't a high five figure amount (aka starting with a 3+).
Re: (Score:3)
We spent over a week hammering out work and time estimates for a large project because management demanded we were going to have a realistic schedule this time. No other work was done. We were in day long meetings knocking out feature requirements and possible work load and time estimates for it. In the end we hammered out a 10 month time estimate (basically the following March) - management turned around and said it had to be out by Christmas and took a "F- it we'll do it
Re: (Score:2)
Do you work at my last company? We spent over a week hammering out work and time estimates for a large project because management demanded we were going to have a realistic schedule this time. No other work was done. We were in day long meetings knocking out feature requirements and possible work load and time estimates for it. In the end we hammered out a 10 month time estimate (basically the following March) - management turned around and said it had to be out by Christmas and took a "F- it we'll do it live" attitude. We sat there afterwards with our jaws on the floor wondering a> Why they didn't stipulate Christmas as a hard deadline to begin with and b> why they made us waste a week on a schedule for an already looming deadline!
I would look at it this way- you took a week to plan the work that needed to be done in detail. That makes it a lot easier to prioritize requirements and cancel or delay them. If they had just given a deadline, the planning would probably be rushed and the project would not start off well organized. Unorganized projects often lead to unnecessary work, rework, and undefined and shifting requirements.
Re: (Score:2)
I once was on a project where a team had to learn a new platform (we were switching from embedded with a *nix dev environment to Windows).
I gave them an estimate of X man-months + 3 CALENDAR months learning curve.
I got back a response that literally said "Work smarter, not harder". (I wish I'd kept that email).
The project was -- you guessed it -- 3 months late.
Re: (Score:2)
I got back a response that literally said "Work smarter, not harder". (I wish I'd kept that email).
I literally got a "Work smarter, not harder" comment on my review for this year by the product manager on the project I mentioned above. Maybe you worked with the same guy in the past.
Re: (Score:2)
Re: (Score:2)
Wait wait wait... where the hell do you get 30k+ bonuses?? I think the biggest I've ever seen was like 4k.
Finance
Re: (Score:1)
Wait wait wait... where the hell do you get 30k+ bonuses?? I think the biggest I've ever seen was like 4k.
Finance AKA ruining the planet in the name of money.
FIXED
Re: (Score:2)
Wait wait wait... where the hell do you get 30k+ bonuses?? I think the biggest I've ever seen was like 4k.
I'll also add, I have found it easier to negotiate for higher pay when you are willing to take a greater portion in the form of bonuses. It is hard to know if a potential hire is really worth a high salary, so if you are willing to take 10%-20% of your salary in bonus your employer can feel more comfortable with your ask. And as long as you are confident in your abilities, when bonus time comes along they don't want to risk upsetting a good new hire. Additionally, once your employer starts thinking of you a
Re: (Score:2)
Am I the only one who can't make head nor tail of the last paragraph?
Re: (Score:2)
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.
Mod parent UP!
Re:Rumination (Score:5, Interesting)
There is a difference between an Arbitrary deadlines vs no deadlines.
Often we will get a deadline, based on the Boss trying to impress a partner, or a customer, or just beat competition to the market. These deadlines are not based on what it would take to do the job right and best. However if someone went to me and say we need to solve this problem, I can usually give a fair ballpark figure on when it can be done by, and add some buffer for unforeseen problems, Then you can have a good deadline, where the project keeps moving and gets done, without stressing and taking shortcuts to meet it.
Re: (Score:3)
Arbitrary deadlines are fine, too. What's not fine are deadlines that don't match the work required. If you give me a month to get a new release of an app shipped, I can do it. If you give me a week, I can do that, too. The difference is that the one released after a week will less than a quarter of the changes that would have been in the one released after a month.
Of course, at some point, a too-fast release cadence can slow down development by requiring you to maintain too much redundant code while y
Re: (Score:2)
These deadlines are not based on what it would take to do the job right and best. However if someone went to me and say we need to solve this problem, I can usually give a fair ballpark figure on when it can be done by, and add some buffer for unforeseen problems
Been there, tried that. The problem is what you might call sub-feature scope creep/unclarity, like say we're going to deliver a car. And everyone has their pet ideas for how every part of it should be different or improved, like it needs a new engine, new gearbox, new suspension, new chassis, new interior, new this and that until not even the windshield wipers are simple. And no matter how much you've reasonable estimated for updates there's always speculative R&D projects or ideas that haven't gotten p
Re:Rumination (Score:4, Insightful)
omnichad observed:
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.
Yep. Making the perfect the enemy of the good is never a useful strategy. It's a prescription for inaction.
Having said that, your first point:
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.
is absolutely the case, IMnsHO.
I'm a writer. A key part of my process is thinking about what I'm going to write. In particular, whether it's a chapter in my novel, an opinion piece, or a feature story, the most important product of my rumination is the opening and closing lines. Assuming I've done the necessary research, and I know the points I want to cover, once I have those taped down, the bit in between them almost writes itself.
If you work in journalism, you write to deadlines all the time. Under that kind of pressure, stuff tends to falls on the floor - and sometimes that stuff is important. For the most part, that's where corrections and retractions originate: the need to get the piece submitted by an arbitrary deadline (trying to "scoop" the competition, as a big, fat for-instance) incentivizes sloppiness. That's why there used to be people called "fact checkers" in the industry - and, believe it or not, they had the power to spike a story, if it contained factual errors (or simply assertions for which there was insufficient evidence).
Now? Not so much. The really big guys - NYT, WaPo, WSJ, etc. - can still afford to pay those people, but they inevitably are a dying breed, like circus elephant trainers. That's driven by economics, of course. As circulation numbers for print media have plummeted like an Acapulco cliff diver, so have ad revenues - and ad revenues, not subscription fees, are where print media makes its principal income. (That's also true of digital publication, where ad revenues are tiny compared to print, so fact checking in the online world is mostly post hoc, and conducted for "Gotcha!" purposes, rather than to ensure the journalistic ducks are properly aligned before you click "Publish!")
The thing is, though, that, for businesses in general, deadlines are a necessary and unavoidable evil. Creative teams rarely work in a vacuum - Google's Project X skunkworks notwithstanding - and it's just impractical to budget and responsibly allocate resources for "When you get around to it ... "
Re: (Score:3)
Re: (Score:2)
+1 to that.
Two obvious examples (Score:5, Funny)
Systemd and Gnome 3. These would have been much better if the deadline was around 2075.
You needed a scientist to figure that out? (Score:5, Insightful)
Re: (Score:3)
Such studies even if it points out something you know is true, you can actually quantify its affect. Because there are also studies that show evidence of things you though were true, to actually be false, or something that has little overall effect.
Re: (Score:3)
Ahh.... open office plans... the problem with your post is that we've known the truth for at least half a decade or more, but you are absolutely right - as long as the work still gets done, it doesn't matter that it wasn't as good as it could have been. Quantity over quality. Actually, even that's not true. In my work environment, open concept didn't improve quantity - it simply reduced quality while also reducing expenses (cramming 4x as many people into the space), and I'm sure some accountant living 1
Re: (Score:2)
shouting down telephones
Even better, putting their phones on speaker so everybody else can hear both sides of the conversation.
Re: (Score:3)
Re: (Score:1)
Agreed. OTOH (Score:2, Insightful)
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).
creativity is overrated in STEM (Score:2)
It's good only for brain storming part, which is the very beginning After that you just apply due process.
Re:creativity is overrated in STEM (Score:4, Insightful)
It's good only for brain storming part, which is the very beginning After that you just apply due process.
Sounds like someone who has never actually done anything that requires actual creativity.
Keep in mind that, each time a Developer, or Development Team runs into an unforseen challenge, that essentially RESETS the "Brain Storming Part" timer. So, in REALITY, "Brain Storming" actually occurs MANY TIMES during EVERY Development Project more complicated than "10 GOTO 10".
If you believe anything else; you're delusional, clueless, or both.
Re: (Score:2)
>So, in REALITY, "Brain Storming" actually occurs MANY TIMES during EVERY Development Project more complicated than "10 GOTO 10".
That is true. Still, it constitutes a small part
> If you believe anything else; you're delusional, clueless, or both.
And you are a presumptuous nincompoop
Re: (Score:2)
>So, in REALITY, "Brain Storming" actually occurs MANY TIMES during EVERY Development Project more complicated than "10 GOTO 10".
That is true. Still, it constitutes a small part
> If you believe anything else; you're delusional, clueless, or both.
And you are a presumptuous nincompoop
But a presumptuous nincompoop with a +4 Insightful on my post...
But often things don't get done... (Score:5, Insightful)
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.
Define arbitrary (Score:1)
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.
Re: (Score:2)
it may be a time=money calculation.
You're right. And if you take this factor into consideration, you might be able to decide you can't afford the project after all. And save yourself wasting a lot of money on a poorly implemented half-done thing.
Re: (Score:3)
How many bosses do you see calculating the time vs reward calculation? Not many. They will normally just use a gut feeling if it is worth it or not.
At one job I had, the Boss gave us 2 weeks to have a demo proof of concepts in front of the customers. No matter how complex it was we had 2 weeks.
Re: (Score:2)
Usually it's the date for a trade show; E3, Expo, SIG-whatever,
Re: (Score:2)
Arbitrary deadline: write it before you die.
It's so fucking arbitrary! Why do people feel a need to pile on these needless conditions?!
Often deadlines are external (Score:2)
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 manage
Re:Often deadlines are external (Score:4, Interesting)
Until a client has informed you that the marketer asked them to ask for a 'very short timeframe' in order to 'motivate the team' you haven't lived.
We found that out...it was the half the team (the competent half) or him. He is still working there. Never so glad to leave a place as that one.
Sometimes it becomes crystal clear what the bastards think. Vote with your feet.
Why even bother with deadlines? (Score:3)
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.
Re: (Score:2)
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,
Re: (Score:2)
Yep.
For the tl;dr folks...Good, Fast, Cheap...pick any two.
Re: (Score:2)
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.
Re: (Score:2)
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 bud
Re: (Score:2)
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
Re: (Score:2)
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 failu
Re: (Score:2)
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 margi
Re: (Score:2)
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 [urbandictionary.com], source [youtube.com], source [youtube.com])
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 t
Programming isn't creative anymore (Score:2)
Re: (Score:2)
Re: (Score:2)
And when they end up managing a team where innovation is critical, they screw up all innovation.
Good point.
I Disagree (Score:4, Insightful)
For proof I submit - Star Citizen.
Different priorities in different scenarios... (Score:4, Insightful)
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.
Re: (Score:2)
Actually, my thought was that for some things, there must be constraints.
For other things, so long as you have a *good* team that is self motivated, allowing the novel things to come as they are ready can work.
Of course, 'when it's ready' sometimes doesn't work and never happens because everyone is *too* laid back, so it's important to read the situation at hand, but sometimes it works great, for at least part of the work
One of the particular dangers of imposing an arbitrary deadline is that something that
Deadlines (Score:3)
Re: (Score:1)
How do you know that His deadlines didn't slip and WE are the slipshod product that was pushed out at the last minute?
Re: (Score:2)
How do you know that His deadlines didn't slip and WE are the slipshod product that was pushed out at the last minute?
"Dear God, I'd like to file a bug report!" - xkcd
Re: (Score:2)
Keep your religious nuttery to yourself.
They're a necessary evil (Score:4, Insightful)
True creativity (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
some out-of-the box solution that may turn out to be vastly more opportune in the long run
Or not. There are reasons that mature industries use standard hardware and construction techniques rather than trying to optimize every design. You want the best houses possible or something unique? We bring in a structural engineer to work out a custom design. Most houses are built with 2x4s, 16 inches on center. Because it works well enough and we can hire guys standing in front of the Home Depot entrance to get it done.
Everybody likes to think that their job falls into the 'creative' category. In point
On the other hand ... (Score:2)
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.
Is time a special case for constraints? (Score:2, Interesting)
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 mo
Be less productive to be creative (Score:2)
Best Busines Reason Ever! (Score:5, Interesting)
This may be generally true, but... (Score:2)
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 p
It's project management (Score:3)
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.
Tree Tap (Score:3)
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.
Between (Score:1)
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.
Creativity and productivity are different. (Score:1)
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 exec
Plans to allow for creativity (Score:2)
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
Without a deadline some creative types dont work (Score:2)
Re: (Score:2)
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
A fine line (Score:1)
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
Semantics (Score:2)
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.
money (Score:2)
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
\o/ (Score:2)
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.