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?
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:
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.
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".
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.
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.
