Being a technical guy, I can tell you that development people have little to no idea of how long things they have never done will take.
I'll say it again: "We really have almost NO idea how long something we have not done before will take."
The problem is that the unknown items can't be known, until they are. That basically means that no matter how carefully you plan, short of actually writing and testing the code, you don't know all the hidden traps that will eat hours or days!
How to deal with that? Set things up so that you can deal with the uncertainty and then keep the pressure on. Read up on Agile Development -- there are a host of similar techniques that all revolve around short sprints to goals, incremental improvements and daily SHORT update meetings. Simply having everybody in the team participate in a daily "standup" meeting where each in turn mentions what they did yesterday, what they plan to do today and what obstacles may be blocking progress. After that brief (we keep it less than 15 minutes) anybody that has no need to follow up with others leaves and gets back to work. People with blocking issues or a need to coordinate discuss in smaller groups as needed.
As a non-technical manager, you should easily be able to monitor the commitments for the following day, see who misses often, notice the issues, etc.. In other words, you will never be surprised at what is happening. And by focussing the team on doing "good enough" for this iteration on the most important features, you can move things forward nice and quickly. What is "most important?" Tasks that help move business goals forward. Engineering should not be doing anything "nice to have" that doesn't materially help the business.