Deadlines Are Killing Us, and Almost Everything Else I Know About Leadership
medium.com
medium.com
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.
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.
From my experience this is arguably the biggest factor I have seen for a project to fail. Not all realistically planned projects are successful but unrealistically planned projects become woolly very quickly.
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.
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.
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.
If you want good quality in a short time -- it'll cost more.
If you want cheap -- you have to compromise on the amount of time or the quality.
I'd argue resource is a better metric than "time", but the point holds for the most part with either.
Artistic things can have deadlines more easily because you can simply decide what constitutes good enough.
Functional things have to work...or they aren’t shipping. They can decide good enough on refinements and UX...as long as it works.
It that sense, there are very few real deadlines around functional things. If it doesn’t work, it’s not shipping yet...meaning it’s not really a deadline.
Not really, choose feature specs or choose a date, not both. Even non-artistic things can have dates, just look at Ubuntu (and now Java) releases.
I'm used to seeing (and feeling) the inverse: people are far too likely to sum everything up into a simple, but too often wrong, explanation (he says with irony) Care to explain your reasoning for why it is overused?
I see it as a form of one upsmanship, like wine tasting when the term is used. Other times, it's used to suggest that there's some detective work going on when the case is not so subtle or sometimes even incorrect. Or maybe I just have a narrower definition of subtle. I also prefer to use the term for analogue things rather than discrete ones. No matter how small a discrete case is clear cut.
You're either going to "hold the release" or you're going to release without the feature...because shipping with the broken feature will only create a huge support burden and a negative perception of your product.
If you order someone to do X, they might, if you ask, the might. But assume that they will do X and you do it aloud, they more likely to do X than in any other case.
I have stolen because it was assumed that I would. And that's totally not my normal style of operation.
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.
If a manager in the org, is producing results using a heavy handed approach, you can be sure your boss is going to be knocking on your door to have a little chat about "improving things" in your teams. It's not a bad thing. Pushes good managers to evolve their own systems.
Time boxing projects teaches people to innovate and become more resourceful. I've seen endless scope creep since starting at my latest company where people aren't help to any type of deadline.
I think the best approach is to have deadlines but allow teams to workout how they manage their time during that window.
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.
Very few people are going to want to be a janitor as their lifelong dream. But there are plenty of janitors who take pride in their work, and pleasure in keeping somewhere clean and tidy, and being appreciated for it. Doesn't mean they wouldn't rather be somewhere else much of the time, but as long as they're doing it they find it rewarding to do a good job.
And you know what's going to make it more likely to have that "kind of" person on a janitorial team? Giving them autonomy, trust, responsibility, psychological safety, appreciation and recognition, etc.
And what's going to make it more likely to have janitors who hate their job, take no pride in it, dread going to work every day, try to get away with the bare minimum, etc? Micro-managing, punishing, not giving them autonomy to do the job in the way it makes sense (as they know best as the one doing it), inconsistency, lack of ownership, lack of recognition.
Because it's not a "kind of" person at all. Some people individually wind up in jobs whose duties necessarily have aspects that are intolerable to them personally and ruin their day, and it would be better for everyone if they could find a different job. But if you are managing or working with a group of people who all or mostly seem to be like this... you didn't hire the wrong people, there's something wrong with the environment. (There's something wrong with a very lot of environments).
Or, as OP says:
> When we try to control people, they become less motivated, less inspired, and less innovative; they do the bare minimum work or they just leave.
(And if YOU are in a place where you hate your job, dread going to work everyday, only want to do the bare minimum to escape punishment at it -- please, for your own sake, try to find another! I know that's sometimes easier said than done and you gotta make rent somehow, but if you are in that place it is destroying your soul and sense of self! You know it, you're miserable -- and it does not have to be that way)
Certainly true in some cases but needing data from the areas and people you manage is an essential need of all management, no matter its style. Tickets, stand ups, daily reports, they’re all ways to make the employee or their work _legible_ from the outside. How that legibility is used is another matter.
In responsible hands, the graphs and metrics from Scrum or Kanban can be used to demonstrate how policies are actively hurting the development team. The information contained in them can tell more tales than just how we could have gotten slightly more done this week.
There may be a lack of responsible hands. It could be that it always has been that case, and you have to promote processes that don't presume an adequate and consistent supply of such hands. I don't know.
But I do know that marching fast to a drumbeat with no clear destination is road to disaster. That Scrum as it is, and even as it was described, is a giant dumpster fire and I lay an over-large portion of that blame at Schwaber's feet.
To put it another way...
We haven't mastered the art of teaching, except to those who have mastered the art of learning
Ours are five minutes long and usually about sharing what we’re all working on and talking about roadblocks.
"The power of instruction is seldom of much efficacy, except in those happy dispositions where it is almost superfluous."
It's from Gibbon's The History of the Decline and Fall of the Roman Empire (Vol. 1, 1776)
https://en.wikiquote.org/wiki/The_History_of_the_Decline_and...
deadlines [...] are designed around the assumption of a
reluctant workforce who have to be clubbed into line
Sometimes it's the opposite of reluctance.
Lots of enthusiastic coders will code away endlessly, never shipping, unless there's some sort of deadline even if it's a self-imposed one. We can see this in many creative and/or engineering pursuits. A passionate writer may revise their work for all eternity without deadlines. Etc.
I recently read a RAND Corporation research paper from the early 90's about command and control, and it gave me new insight into how a C2 system supports a commander (or in a business case, the CEO).
The things that you mentioned (status reports, daily standups, tickets) are not for "clubbing the workforce", they are for feeding information to the CEO/commander about 3 things:
-does the organization understand the plan the way the CEO does? -is the organization executing the plan correctly? -is there information that requires the CEO to change the plan?
It's not about "the beatings will continue until morale improves".
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.
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!"
> 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.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
"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.
I'd read that as two requests.
1) "Make a tool that does X."
2) "Fast track a tool that does X by Friday so we can do Y."
The use the time prototyping X quickly to learn the entire space around solving the problem X, while mostly aiming to just solve the parts of the problem that will roadblock Y, with the agreement that this is only a prototype and while the Y team may choose to put it into production, there'll also be a much more complete set of requirements and specification of "The X tool", (which may well include Rust evangelism, proper testing infrastructure, performance benchmarking and scaling plans).
(Note: _most_ of the time this does not actually get acted upon, and I've got several hilarious war stories about "quick hacks to get us past next week's deadline" that out survived the company that I implemented it for. But a least I had it in writing...)
That’s a quote from Fred Brooks’ The Mythical Man-Month (1975):
”[…] plan to throw one away; you will, anyhow.”
It'll take some time, though, for a manager to learn that a particular person can be trusted with a hands-off style. I've tended to default to hands-off as a manager, sometimes with expensive results.
In the long run micromanagement sets them up for failure. You're not going to be there for them forever. If they can't improve their organization skills to a point where they can complete work on their own, then they might not be suited for their job.
Generally I unconsciously categorize tasks that I remember I need to do* (or that a task list helps me remember) a kind of emotional score relating to their ease of accomplishing, the need to get them done today / sooner vs later, and how big a work slot I feel I have to pack them inside of.
I have noticed that tasks which are perceived as easy or quick to accomplish tend to get fulfilled faster; I can clear the item out of my mental list and it can be squeezed in to moments that would otherwise not be productive.
Tasks with external dependencies (meeting others, scheduling anything at all with anyone else, waiting on external approval processes) are clutter that stuffs up my mental caches, but isn't quite something that I can clear out either.
The inability to clear those things out becomes a type of stress, and creates a negative feedback loop of it's own.
Foreknowledge of those issues, as well as scheduling constraints for doing things, often leads to the estimation that a task which might otherwise be easier (for example if moving fast and breaking things) to cost more (only break things during limited, pre-announced windows).
There's only so much value in celebrating having the first half of the car put together. It still won't tell you when it's ready to ship. Especially if you've assembled it in the wrong order...
Instead: let's ship the best working car we can by <date>! And here's why that date. Who has ideas for how to get an even shittier completely working first-iteration done six months before that? Now, go figure it out and make it happen. I trust you. (To self: and I'll trust you even more as I see each shippable iteration that you enjoyed making.)
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.)
Rule number one of writing is to be willing to cut some good material out because it does not fit your current piece.
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.
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.
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.
Also, do you think your productivity was equivalent to 32 engineers? Regardless of what your manager said.
Another example like this (from later) was when I designed a context-switchable HD MPEG-2 core with two other people. We had the CEO/CTO of a start-up come in to pitch their supposedly equivalent core to us. They had a company of dozens of people who had all been working on the project for a couple of years. We had been working on our project for six months and we were much further ahead in development than them.
It seems to me that the performance and quality bar is just really low in general. Execution is way lower than it could be. I can only imagine that it's a motivation problem.
I 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.
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.
There is room between these 2 extremes. A team that follows KPIs or some kind of agile process, for example.
"Not sure, the software developer team doesn't like deadlines, they'll be finished when they feel like it."
Most of us aren't writing code that will go to space, but most of us work with other parts of the business, and marketing, management, investors need agreed deadlines to coordinate with.
If you're competitor is imminently releasing a competing product then what you're working on isn't really novel. It would also be potentially patentable if it really was novel, which would grant you a monopoly on the space.
> As well as this, the time between having a product or feature complete and ready for release equates to lost revenue.
What's the lost revenue from releasing a buggy product? What's the lost revenue if your competitors are about to release a working one? What's the lost revenue from your developers jumping ship and all the related turn over costs? Some of those mistakes could sink the product/business entirely.
> to maximise possible revenue.
You agree that maximizing revenue at the expense of everything else isn't the goal don't you? If that's all that mattered then development would be outsourced to a third world country to save on expenses. But we've mostly learned no to do that because despite promising revenue gains they lead to several bad outcomes in the short and long term, pushing hard deadlines is no different.
"Yes, it will. But we can't guarantee it will work correctly."
Choose your poison.
But that bootloader had better be flawless!
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.
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.
Custom/self builds are famously hard to predict, and nearly always go massively over budget and over time (twice as long, twice as much is more common than on budget, on schedule). Often because there are significant changes to the requirements as the project goes on, because the customer changes their mind, or because unexpected things are discovered during the build.
In fact, with the arguable exception of teaching, which is a classic example of deliver to deadline with no specific set of features, all of your examples are things that people are unable to accurately predict.
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.
So why the hate for deadlines? Software engineering does not exist in vacuum separated from business constraints like runway or annual budgets. To demand deadlines of your employer but to not be willing to even try to meet deadlines in deliverables seems to me to be a bit unprofessional and disconnected from the underlying business reality. A whole company that wants to shrug off this underlying business reality seems even worse. A series B startup that doesn't meet deadlines might not even be in business in 6 months.
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.
I think this was probably one of the better articles I've read about leadership; but then, it confirms most of what I believe.
> [...] The 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 [...]
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.
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!"
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.
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.
There are many such hard deadlines in life, and failing to recognize them and motivate your team to meet them is poor leadership.
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
Setting deadlines is useful for planning. Respecting them at all costs is dangerous. They need to be updated when we have more information.
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.
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
Unnecessary deadlines = unnecessary tradeoffs.
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.
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.
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.