A non technical manager keeps arguing that the team should code faster to deliver on the scheduled release date. We tried explaining that issues arise, thinking and coding simply cannot be sped up to meet a release date.

How to explain in simple terms that we cannot simply code faster?

  • 4
    What is your question? – Matthew Gaiser Nov 3 '20 at 9:03
  • 1
    Who sets the timeframes and what criteria do they use? – Kilisi Nov 3 '20 at 11:06
  • 5
    The faster you code, the more bugs you introduce. Bugs are expensive to fix, especially if your QA is inadequate. – Dan Pichelman Nov 3 '20 at 11:38
  • 25
    why doesn't he just manage faster? – user253751 Nov 3 '20 at 16:15
  • 1
    Give them a copy of "The Mythical Man Month" – Glen Pierce Nov 6 '20 at 3:54

My usual technique with the business vs. tech problems is to get into the question of what does the business actually need. Since I know the tech and generally know its hurdles, I can sometimes come up with a way to get the bare minimum business goal done within the limits of the tech.

If that fails, then I go into ways of estimating and quantifying time that actually make sense, vs. the lines of code per time window metric. I put an estimate on design tasks, implementation tasks, testing tasks, etc, ordering them however my planned process would suggest (TDD, waterfall, straight up Agile, etc). Usually the business people's eyes glaze over at stuff like "story point estimation" and so forth, so I bubble it up to things like "in x weeks, we can get a feature like this done. The thing you want is n times that because...", where I'm picking a feature that this person would understand and remember, so I can then talk about why what they want is different/bigger/harder in scope. And my "because..." works best when it's REALLY high level and light on detail/accuracy - for example:

  • hard because I have to make our code work with our partner's system. This kind of work always involves a lot of surprises.
  • hard because I haven't tried this kind of thing before - I've seen it done many times, so I can get working examples, but it'll be new to me, so I need to plan some time to learn some new stuff.
  • hard because there's a rock and a hard place - the requirement to X in real-time means that we have to take extra schedule time to build, test, and verify that it really is as fast as you want it. If all we had to do was X, we'd meet your schedule easily, but needing to meet max time limits adds a seriously level of difficulty.

At that point, you can also expect you may get counter proposals (what if we hired someone who knows stuff you don't know?) - which is reasonable for a manager to do, as long as the manager is realistic about the limits of reality (time to hire, time to train, etc).

Bouncing back and forth between trying to find out what the simplest way to get the business need accomplished, and yet explaining why the business need being cited seems undoable in the time allowed has given me enough traction to get to a mutually agreed upon release date most times. I've certainly had times where I couldn't succeed - particularly on really big projects with a huge number of moving parts and unknowns. But on things of 1-6 months duration for 2-5 people, I've had reasonable success.

  • I know it's adding to already "old" (few days) question, but I just have to mention imgs.xkcd.com/comics/tasks.png in relation to task complexity and estimates :) – mishan Nov 9 '20 at 22:26
  • 1
    The best way to answer this is definitely as this answer suggests, with figures and data. At the same time, you need to give options; management likes to feel in control, and they don't like to feel they're powerless. A good solution is not merely to say "This will take 6 months", but to say "in 3 months we can give you this..." – Stuart F Nov 10 '20 at 10:43

Tell the manager that he should double all the salaries to deliver on the scheduled release date. (Does that make sense? To some degree yes. ) The point is of course that now you've put the manager on the backfoot: He now is asked to argue why that is a bad idea, when all the developers think it's a great idea. He'll probably something like "I can't just pay you all twice as much. " And there the trap is sprung, because you say "and we can't just code faster".

  • 1
    People please upvote this for being concise and unbeatable in its power of explanation :-) – puck Nov 4 '20 at 15:09
  • 1
    Be careful what you wish for. The problem with a bluff like this is that even if the whole team agrees, you can't expect to get double the output by doubling your hours, or turn a junior into a senior by increasing their pay, so you can't back it up if the pm agrees. – IllusiveBrian Nov 5 '20 at 21:13
  • 2
    @IllusiveBrian There are worse problems to have :-) – gnasher729 Nov 6 '20 at 8:00
  • Seems like this could backfire completely if the manager calls your bluff. – user46126 Nov 9 '20 at 19:58
  • This is a bit dumb, and I'm sure it won't be seen as helpful or practical by your manager. It's far better to come up with an actual solution like "we can get it done if we drop X features". – Stuart F Nov 10 '20 at 10:45

We tried explaining that issues arise, thinking and coding simply cannot be sped up to meet a release date.

This is false. A team can always deliver faster. For example, I can give you a rocket firmware in any deadline you want. It's gonna print "Hello World!" and exit. It compiles, works and passes tests. And is on time.

In other words, requirements negotiation is far more important than the actual development.


There are a few ways you can explain it, with various degrees of respect and professionalism. Depending on how many times you've tried to explain it and how pushy the manager is, you can try some of these:

Your manager doesn't understand what "engineering" means. They're used to reports. You have the data, you open MS Word, you copypaste in some charts and write like 2 paragraphs, you print it and put it on the CEO's desk, and you get a $10k raise at the end of the year. You don't question where that data came from, who made it, what sorts of analysis goes on, and so on. So you have to explain that to your manager: building software isn't just mindlessly jamming on a keyboard, there are other considerations to building good software, like planning, designing, and so on. You occasionally have to learn to use new tools or languages or frameworks in order to make things work and make them continue working. If you fail to do these things, then the server stops working and the website crashes and your customers get mad and you're all out of a job.

To be slightly more passive-aggressive, you can explain that you are very well-paid for your job, and the reason you are well-paid is because you are skilled. Part of that skill means anticipating problems that may occur and trying to fix and solve them before they happen. If the company wanted, they could outsource your job to some codemonkey in India who doesn't know anything, but they can get the job done in 2 weeks. It probably won't work, the servers will crash relentlessly, your customers won't be able to use the product and they'll hate your company, but it will be "done". That's why you are working at the company instead of hiring an outsourcing firm even though it's more expensive to do it that way.

To be extremely passive-aggressive (actually just plain aggressive) you could ask them why they can't just manage faster, or why they can't write their reports faster or hold their meetings faster. The faster you work, the more mistakes you make; clearly this manager doesn't want to make mistakes in their own job, that's why they don't work as fast as they "can" (I say "clearly" because everyone does this). You don't want to make mistakes, so you do everything deliberately to make sure that you make as few mistakes as possible.

If this manager is not your manager, you may want to have a chat with your manager and make them understand that doing things like rushing timelines and skipping QA can have lots of problems down the road; these things are very important, more important indeed than providing the functionality. You need to tell him that he needs to step up and push back against business when they ask for unrealistic deadlines, and to communicate more with his team to make sure that everyone is on the same page. Companies in which business assigns engineering timelines are companies that fail; companies that succeed have business create a feature list and engineering create a timeline of when that feature list can be completed, properly and accurately. If you fail to do this, it's not an issue of making the employees upset; it's an issue that when you ship bad code, it reflects in the user experience, and the user experience affects the bottom line, and the bottom line affects whether you have jobs at all. You want to keep your job, and so does your team, and if your manager also likes his job then he should listen to you because otherwise the company could disappear. Those are the terms you should explain it as.

  • 4
    telling the manager that what they know is just "mindlessly jamming on a keyboard" and that unlike the manger, you're skilled, is unlikely to foster an atmosphere of co-operation. And patronizingly explaining that bugs are bad won't help: this manager doesn't "get" that skippng steps makes bugs -- it's not that they aren't aware bugs are a problem. – Kate Gregory Nov 4 '20 at 0:04
  • @KateGregory Wow, that's certainly one reading of what I wrote I guess XD – Ertai87 Nov 4 '20 at 15:38
  • @Ertai87 I had the exact same reading. Seems to me like your answer is needlessly antagonizing to the manager and isn't likely to help the situation. – user46126 Nov 9 '20 at 20:00

How to explain in simple terms that we cannot simply code faster?

This is the hardest part of working for someone who has never coded before. They do not always understand that sometimes the hardest part is thinking through the solution. You have to know what your doing, what technologies are required, etc. before you can simply code a solution.

The best thing you can do it to try and explain the process as thoroughly as you can, emphasizing the fact that thinking doesn't always equate to shippable code. If you can, use a current task/project/story as an example if you can.

If your manager doesn't get this fact, you may be in for a long and painful career.

You also should consider that no matter what you say, the manager just wants x done by y, and does not care that sometimes it is not possible to hit an arbitrary date.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .