The 5 most common mistakes of managers and how to avoid them
As a developer, fake deadlines drove me crazy.
I always feel responsible for delivering on time, so I used to work my ass off (weekends and nights included) just to meet a random date. And then… Silence. Nothing happens. The press release is not planned for a month yet, or another team is delayed so we just need to wait.
That was so frustrating!
Once I became a manager, I finally saw why they were needed, but felt guilty about using them.
Then, 9 months ago, I read James Stanier’s post about fake deadlines. Finally, it all clicked, and I shared that one with my team and manager.
So today, he agreed to share his take with you!
grew from engineer to SVP of engineering at Brandwatch, and is now a Director of Engineering at Shopify. In-between he wrote Become an Effective Software Engineering Manager (one of the best books for engineering managers), Effective Remote Work, and the recently released Become a Great Engineering Leader (for Director→CTO roles). Somehow he also finds the time to write - a must-subscribe for EMs!
Passing the mic to James 🎤
*Non of the links are sponsored/affiliated
Parkinson's Law states that "work expands so as to fill the time available for its completion."
Although it is counter-intuitive, you will find that through practice and experience, there is a lot of truth to this. Projects that don't have deadlines imposed on them, even if they are self-imposed, will take a lot longer than they need to, and may suffer from feature creep and scope bloat.
By setting challenging deadlines you will actually get better results. It's all about manipulating the Iron Triangle of scope, resources, and time.
If you've not come across the Iron Triangle before, the idea is that it represents the three key constraints of a project:
Scope - the work that needs to be completed.
Resources - the people and tools that are available to do the work.
Time - the amount of time that you have to get it done.
You can't change one without affecting the others. For example, if you want to do more work, then you're either going to need more people or more time. It's the embodiment of the "pick two" rule: you can have it good, fast, or cheap, but you can't have all three.
Back to Parkinson's Law: without tight time constraints, the scope of a team's project will expand to fill the time available. This is just human nature. Just look at how long those little DIY jobs around the house take to get done. With no deadline, there's no urgency, and so things just don't happen.
So, deadlines work.
Now, the usual hip-shoot counter to deadlines is that "fake" deadlines lead to poor work being done, and, look: there is sometimes truth to that.
However, that situation occurring typically represents poor application, rather than issues with the methodology. Putting challenging timeboxes on projects in a healthy environment can lead to serious innovation and creativity.
Doing the same with impossible timeboxes in a toxic environment will lead to all of the bad things that you expect.
Deadlines really help human beings get things done. The only way that I've written books is because I set myself a challenging, but not impossible, schedule with the publisher. This contract of external accountability keeps the fire going through the long slog, and it forces me to make clear-cut decisions about what to include, what to leave out, and how to manage my spare time so I make progress.
The exact same thing is true with communication and software projects.
When you are asking people to do something, lead with a recommendation of when it should be done by. Be explicit about this, but open to negotiation. It's such a simple technique, but when you compound its usage over a year at a big company, you will be amazed at the difference it makes.
Deadlines force a clear tempo and cadence and, fundamentally, they make things happen. A canonical example of this is sending round a survey that can be filled in whenever versus one that needs to be filled in by tomorrow: just by asking, you will get a much higher response rate far faster. Learn from this, and apply it to your own communication.
Even though you may not think that people want it, and even if people themselves think they don't want it, knowing that things need to be done by deadlines that are just on the cusp of the comfort zone forces real, tangible progress.
If you think that a prototype might take a month, why not challenge the team to see what they can deliver by the end of the week? You will be surprised, and so will they.
When wielded with grace, good intentions, and knowledge of what gets humans moving and feeling good, deadlines are a powerful tool.
Parkinson's Law is real, and you will need to fight it harder the larger your organization is. If you can succeed in this fight, you can grow and still ship fast with an org size of tens of thousands. If you don't, then one day you'll look around and wonder why your startup turned into the software equivalent of the local council's tax office.
Fight the drag. Set a deadline.
Anton here - thanks James for his take. After reading it, I understood that I was doing a disservice to the team by fighting every fake deadline. It’s a powerful tool, and I was ignoring it just because I was burned by it a few times before.
Here are some mistakes to avoid:
I made sure to not repeat what annoyed me as a developer. It’s completely ok to not have anything external happen when the deadline arrives!
That doesn’t mean the effort to meet it was wasted. You built trust with the rest of the organization and you freed yourself to work on other things.
If you set the expectations right, people won’t be disappointed.
Deadlines work best when the team takes part in deciding the scope that can be achieved. It doesn’t mean you need to reach a consensus, it’s ok to take a different decision - as long as they were part of the conversation.
Imagine the frustration of starting on a project you know from day 1 you won’t be able to achieve on time. If your engineers think “If only somebody asked me…” - you failed.
The whole point of the deadline is to get the team focused on the goal. Even if you all agreed together about the achievable scope, things change.
Maybe you encountered an unexpected obstacle, or were blocked by another team for a week. Or maybe it just took more than you anticipated.
Being very strict with the rules, and priding yourself that ‘my team always delivers on time!’ can create unnecessary conflicts. It’s probably better to miss a fake deadline once in a while than make your team work extra hours and weekends (even if you pay extra).
The other side of the coin. Some managers try very hard to please their team, and are afraid to demand more from them. In some cases they even try to compensate by doing it themselves (especially first-time managers).
It’s ok to ask people to work a bit harder. It’s your job to find the right balance.
Sometimes external people will want to change the deadline (especially your PM), or add some scope. Your first instinct might be to respond by saying: “No way, we agreed to X by Y. We are not changing that right now”.
You don’t want to look stupid in front of your team, which worked hard to finish by date Y.
That’s understandable, but don’t let it drive you. Going back to #1 - people are not stupid. As long as you communicate well, they’ll understand.
Read the original article
Comments
> It’s completely ok to not have anything external happen when the deadline arrives! That doesn’t mean the effort to meet it was wasted. You built trust with the rest of the organization and you freed yourself to work on other things.
Does it usually motivate people to work hard, when they know the outcome of the crunch is "more trust with the rest of the organization" and "now I can work on other things"? Sounds pretty dystopian to me, and not all what motives me to do good work.
I think if someone pushed me to deliver something urgently to hit a deadline, I'd expect that deadline to have some sort of meaning, not just "now others trust you more". If no one actually needed that thing at that date, why was I being rushed to finish that specific thing for that specific date?
100000%. If I was put through stress to to meet a deadline that I later found out was totally arbitrary "So that I can do more work". I would instantly lose motivation. Everything is made up and the points don't matter. Got it.
Someone should make a modern day boy cried wolf story except it’s with software engineers and fake deadlines.
By atoav 2025-04-0217:14 My pet peeve is that in the boy cried wolf story in the end the wolf was real and the boy got eaten.
Imagine a real village where a boy sees a wolf and three times the villagers run out and don't see a wolf and then one day the boy cries wolf again and gets eaten — which is more likely:
1. The boy lied to the villagers about the wolf and then by a turn of fate a wolf showed up.
2. The boy actually saw a real wolf, but that wolf evaded the villagers, then the villagers let the boy get eaten and out of shame they started telling the story in a way that tells us the boy lied, even if he didn't. That boy had it coming. He always was a bit misguided — says the person who thinks death is an acceptable punishment for lying.
I find the latter way more likely and the lesson to be learned from it more profound.
By m463 2025-04-030:34 don't they do it with wait-i-didn't-mean-it-layoffs and fake job interviews?
By BuggieSmalls 2025-04-031:21 The DevOps Who Cried Deadline
Once upon a time in Silicon Valley, there was a product manager named Maxwell who oversaw a team of talented software engineers at TechNova Inc. Maxwell had a reputation for creating a sense of urgency to "motivate" his team.
"We need this feature deployed by Friday!" Maxwell would announce dramatically during Monday standups. "The investors are coming!"
The engineers would frantically work late nights, skip lunches, and cancel weekend plans. They'd push code furiously, cut corners on testing, and deliver by the deadline—exhausted but proud.
But Friday would come and go. No investors appeared. The deployment would sit unused.
"Great work, team!" Maxwell would say. "The investors rescheduled, but we're ready for them now!"
Two weeks later: "Critical deadline this Wednesday! The sales team needs this dashboard for a major client demo!"
Again, the engineers would scramble, work overtime, and deliver—only to discover the "major client" had merely expressed passing interest in a product roadmap conversation.
*The engineers began to notice the pattern*. Their trust in Maxwell eroded with each false alarm. Some started working at a measured pace regardless of the supposed urgency. Others began looking for new jobs.
During one team meeting, a junior developer named Zoe spoke up.
"These deadlines don't seem to connect to any real business need," she said. "Are we just manufacturing urgency?"
"You don't understand the bigger picture," Maxwell replied dismissively. "Sometimes we need to push ourselves to excellence."
Months passed. The team grew increasingly disengaged. They'd nod during Maxwell's urgency announcements but work at their own pace. Productivity actually improved as they focused on quality rather than rushing.
Then one day, Maxwell burst into the office genuinely panicked.
"The production server is down! Our main authentication service has been compromised! We have *three hours before all user data is exposed*!"
The engineers exchanged knowing glances. Another fake deadline.
"Sure thing, Maxwell," said the lead engineer without looking up from his mechanical keyboard. "We'll get right on that."
"No, this is real!" Maxwell insisted, his face pale. "The company could go bankrupt if we don't fix this NOW!"
But *no one moved with urgency*. Some engineers continued working on their current tasks. Others took their scheduled lunch breaks.
As the actual deadline approached, Maxwell grew increasingly desperate. He tried pulling individual engineers aside, even offering bonuses, but years of crying wolf had rendered his pleas meaningless.
The breach was catastrophic. By the time the team finally understood the gravity of the situation, it was too late. The hackers had extracted the entire customer database, including payment information and personal data for over 12 million users.
The following Monday, the once-bustling office was eerily quiet. Security guards stood at the entrance, allowing employees in only to collect personal belongings. TechNova's stock had plummeted 87% overnight. News vans crowded the parking lot.
Maxwell sat alone in his car, staring at the termination letter. His phone buzzed constantly with notifications from class-action lawsuits naming him personally. His industry reputation was irreparably damaged.
The engineers fared no better. With "TechNova" on their resumes now a scarlet letter, they faced grueling interviews where they had to explain their role in what tech blogs were calling "The Deadliest Deadline." Many would remain unemployed for months.
Zoe, who had questioned the deadline culture but still failed to act when it mattered, couldn't shake the guilt. "We knew better," she told the investigative committee. "We just stopped caring."
In the tech campuses across Silicon Valley, the cautionary tale spread quickly. Companies instituted new protocols for emergency response, but the deeper damage was psychological. In an industry built on trust between managers and builders, the TechNova incident laid bare how completely that trust could collapse.
The tragedy wasn't just the breach itself — it was that a team of brilliant people had become so desensitized to false urgency that they couldn't recognize real danger when it finally arrived. The wolf had finally come, and no one believed the cry until it was too late.
By mroche 2025-04-0214:50 [flagged]
By memhole 2025-04-0214:35 This is called the hamster wheel and destroys trust rather than builds it, ime. Maybe it communicates trust to the org? The people within the team will question the motives. One piece of advice I read early on, was don’t bullshit your engineers. They know.
I’m a big fan of value as prioritization. Work on the things that deliver value. However value is defined. Revenue, nps, etc. Ime, small companies don’t care about deadlines or they shouldn’t. They care about what’s delivering value or the next outcome. It’s only as you grow the company suddenly people want deadlines. Or you have small companies that misunderstand what their focus should be. There are obviously some time constraints that need deadlines. You can’t work on something for the holidays and deliver in Feb.
By FirmwareBurner 2025-04-0214:221 reply >I'd expect that deadline to have some sort of meaning, not just "now others trust you more".
Every place of work where I saw that being pushed and accepted once, then crunch just became the new norm over time, 100% of the time.
Developers accepting the crunch to please management, signals to management that they can outsource the externalities and consequences of their bad estimations and planning onto the developers without consequences while they collect the bonuses for the deadlines being met.
While on the other hand, pushing against the crunch when/if you can, forces management to be more careful and realistic with expectations, basically to do their fucking job right.
By AnimalMuppet 2025-04-0214:312 reply But they actually aren't leaving productivity on the table. This isn't an assembly line. Crunching makes you tired, and your brain slows down when you're tired. You wind up doing the same work in a 10-hour day that you would have done in an 8-hour day.
Extreme programming (XP) was all about going as fast as you can. One of the rules was, "Never work overtime for more than one week in a row." Why? Because when you're tired, you slow down. When you're tired, stop. Go home. Get some sleep. Come back tomorrow with a brain that isn't tired.
By steveBK123 2025-04-0214:36 Yes, and I'd add further - this is knowledge work. Creating a mentally/emotional safe environment is going to enhance productivity more than shouting at people.
Shouting at a team is a good way to burn a day of productivity and months of built up good will. This should be obvious, and yet I still see about 20% of managers do it.
By FirmwareBurner 2025-04-0214:322 reply >Crunching makes you tired, and your brain slows down when you're tired.
Sure, but management doesn't care about the health of the workers, they care about line going up, for them workers are replaceable cogs. If people are too slow and tired from crunch, then it's their problem, so you put them on pip then fire them and replace them with fresh hires. Rinse and repeat. It is only a problem for them, if they manage to burn through all their cogs and have no more replacements. But then there's immigration and visas.
I've seen this twice already where I worked.
Wasn't Japan the country where people even die from overwork? If management saw this as a problem, surely they would have put an end to it by now and give workers there a French/Danish work-life balance instead to increase their productivity, but it seems like that's not how companies view productivity.
By AnimalMuppet 2025-04-0216:021 reply Let's suppose I was a manager who only cared about line go up. And let's suppose I was able to think about second-order effects. What would I do?
I would care about not burning out my programmers. Burned-out programmers program slower, not faster. Slower doesn't make line go up. Sure, I could get faster... for a week, maybe two. After that it's counterproductive. If I don't really need it, right now, then I shouldn't do it.
Same thing with workers leaving. Sure, I could hire more, but training costs. I spent a lot of money getting the ones I have now to learn what's going on well enough to be effective. If I care about line go up, I don't want to lose those people.
Extreme Programming (XP) was all about going as fast as possible. One of their rules was "Never work overtime longer than one week in a row." Why? Because programming isn't an assembly line. Tired people miss things. They write more bugs. They just work slower. If you want to go as fast as possible, be rested. When you're tired, go home. Get some sleep. Come back with a brain that works.
Look, a decent human being should have some empathy for other human beings. But even a manager with no empathy whatsoever, if they understand, still shouldn't be making their programmers work crunch time except in very short, rare amounts.
The problem isn't just managers who only care about line go up. It's managers who do so in a clueless way.
By franktankbank 2025-04-0218:271 reply No you'd just outsource to India and cycle through as many billions of souls needed.
By AnimalMuppet 2025-04-0219:201 reply You'd still have to bring each new hire up to speed. Still not a smart plan.
By disgruntledphd2 2025-04-0314:24 Generally people forget to consider replacement and training costs as reasons to be kind to your current employees.
I've basically never seen this happen in my career (although I live in hope).
By steveBK123 2025-04-0214:401 reply Not sure why this got downvoted, management really does not care about your health. They may say things out of social niceties, but they really do not care. Maybe if it causes their cost share of your healthcare plan to go up they might, but not really.
By FirmwareBurner 2025-04-0214:501 reply >Not sure why this got downvoted
Because HN doesn't like comments that are blunt about harsh realities, they like a warm tone that coddles and softens the facts.
>They may say things out of social niceties, but they really do not care.
My favorite part is when companies pretend to tackle burnouts with giving their workers subscriptions to yoga or mindfulness apps, instead of you know, the sane thing that actually works, which is less workload and a less toxic work environment.
> Maybe if it causes their cost share of your healthcare plan to go up they might, but not really.
Would be nice if that were the case. I live in a country with universal healthcare, so all the externalities of burnouts get socialized from the private system to the state healthcare and welfare systems, not to the employers. It's incredibly rare that an employer here is reprimanded against stress induced onto the workers. Only if there's hard evidence proving the employer is the cause, or an employee kills themselves you might see the state looking into it and fining the employer.
By steveBK123 2025-04-0215:21 I've also noticed, especially in the last 6 months, any threads going too far in questioning paymasters here quickly gets downvoted/filtered/disappeared off main page quite quickly.
By mystifyingpoi 2025-04-0214:30 Yeah. Organically, over time, someone will step 1 day over the deadline, then 2, then 3, without any consequences. Over time, engineers will figure out the "real" deadline, and learn to ignore the useless lying manager.
the most demotivating moments in my professional life were when i just hit some manager’s deadline and the project didn’t go live for months after that, or adopted by the target consumers, etc
By palata 2025-04-0215:54 My manager gave me a fake deadline (pretending it was not fake, of course) and almost declined my vacation request right after it "in case I couldn't meet the deadline". I committed to finishing my work before leaving on vacation.
It was a tough deadline. I worked during the weekend and few nights before my vacation to meet it. I finished on time and left quite exhausted, but happy I made it.
NOTHING happened with my work in the next 2 months. I asked my manager and he finally said "oh yeah, the deadline is in 2 weeks"... so I asked why I had worked like an idiot before my vacation. His answer: "I did that to help you organise". I kindly told him that I didn't need his help to organise my work and that I would like him to never do that again. He answered that "I understand your feeling, but I will keep doing that, because I am convinced it helps you even if you say it doesn't". That's not the only time he screwed me like this.
I never trusted that guy again. I've seen him take wrong decisions and let him. I've seen situations where he was struggling and I could have helped, but didn't. And when he complained about bad decisions later, I happily reminded him that he took them.
A manager can choose to play with me or against me. But if they play against me, it means I play against them. And once they've brought me there, I'm not coming back in their team, ever.
It's easy to break trust, hard to rebuild.
By stronglikedan 2025-04-0214:34 We call that "hurry up and wait!" around my parts.
Yeah, I feel like he sunk his entire post with this first learning.
What's the point if nothing happens?
It doesn't have to be "we ship to a million users".
It could be simply "The CEO will then test the flow and give their feedback".
Then, those stakeholders have to hold up their end of the bargain as well, actually use the feature, and give thoughtful feedback. If they don't reciprocate, the future of all fake deadlines is in jeopardy.
By steveBK123 2025-04-0214:38 The pressure to deliver and complete dereliction in giving feedback is what breaks the loop for engineers .. completely demotivating
By jasonm23 2025-04-033:11 Frankly the correct answer to the post's headline is an emphatic:
DON'T
Fake deadlines suck. They cut against high-trust teamwork. They obscure real deadlines, including real commitments to customers.
The author writes "Once I became a manager, I finally saw why they were needed, but felt guilty about using them."
You SHOULD feel guilty. Truth matters. Trust matters.
If you're having problems with estimation and planning, then success looks like working on these areas-- not faking them.
Good tactics to try are work breakdown structures, planning poker, transparency for timelines, good project management tooling, critical chain scheduling, and above all trusting your teammates.
By mytailorisrich 2025-04-0214:38 I think transparency is a good policy and helps provide context and meaning, and actually builds trust.
So "fake deadlines" aren't needed. It is perfectly OK to show the plan to the team and to explain that, for example, the committed plan is that the test team will start overall testing on 1st May so we have to deliver our software to them no later than the week before. And then you can tell the team that you set the target date in advance of that to account for any issues and delays.
Now this is a real deadline and everyone knows why it exists and why it matters.
Now, if that 1st May was a "fake deadline" set above your head at least you are 'clean' and get to keep you leadership status among your team.
By josfredo 2025-04-0214:38 I think the pragmatic consensus is: feel guilty about it; then do it anyways.
> In some cases they even try to compensate by doing it themselves (especially first-time managers).
It’s ok to ask people to work a bit harder. It’s your job to find the right balance.
It’s an error to work as hard as you ask your subordinates to, in service of an arbitrary deadline you cooked up just to put pressure on them?
> I always feel responsible for delivering on time, so I used to work my ass off (weekends and nights included) just to meet a random date. […]
Once I became a manager, I finally saw why they were needed, but felt guilty about using them.
Perhaps it’s worth listening to that twinge of guilt. There’s nothing virtuous about tricking or cajoling people into that kind of a cadence—especially just as routine way of running your shop. Emergencies, maybe—real deadlines, maybe—but run a respectful shop and I bet people will step up when times call for it.
By lanyard-textile 2025-04-0214:321 reply It is not a fun reality — but in a business where profit is the goal, cadence deadlines are helpful.
When used right, they give you a good gauge on how much time the company would like you to spend on the problem. Ideally they calculated that risk higher up for the business’s needs, and you are being assigned the work for a strategy.
The frustrating part is this rarely happens in practice :) I’m working at a place now where they actually do this, and they strike the right balance: Not too demanding, but gives a good idea on the effort I’m expected to give for this, and my work clearly has an effect on the grander vision.
I can make a beautiful program in one month — or I can make some compromises and get it out by Friday. That’s programming vs. engineering.
That makes a lot of sense to me. I think I reacted more to the idea that fake deadlines are an appropriate technique for the purpose of squeezing people until they always scramble through their nights and weekends as a routine matter, like this guy seemed to like to do when he was on the front line.
“We’re going to spend the next two weeks working on X, so scope your ambitions accordingly—what’s realistic to expect in that timeframe?” seems like a perfectly reasonable and healthy negotiation to have, one compatible with respectful working relationships.
By lanyard-textile 2025-04-0319:43 Yeah I see what you mean too :) It is big suck.
By steveBK123 2025-04-0214:45 This kind of behavior also rewards the wrong behaviors. A lot of "I think my team isn't working hard enough" is optics not output.
It's very easy to be performatively more busy to please these types of bosses. This does not add any value and erodes trust. It also makes me lose all respect for a manager when I feel I need to do this.
