I am going to start by saying that hiring someone to oversee the progress of 2 resources is a bit of an overkill. Also, it is important to understand what kind of development they do for you. I am going to assume it's some sort of a web tool, in any case something that has an interface, with features that are easily evaluated by a non technical person.
I have led quite a few teams so far and there were a few cases in which I wasn't very well acquainted to what they were doing, at least at first.
What helped me gain some control and some confidence in the work they were doing was an Agile approach. Of course, I am not talking about a full Agile implementation, but the Sprint approach to building software is a very handy trick.
Basically what you want to do is set up with them a feature backlog - things that you want them to develop in the near future. After that, as my predecessors have already said, ask your developers to break the features into smaller tasks, none bigger than 8h. If it's bigger, in 95% of the cases it can be broken further.
Now establish your sprint length - it's usually 2 weeks. The trick is that at the end of the 2 weeks, you developers release a piece of working code. It may not be complete, but it has to be working.
You plan with them the 2 weeks, based on their own estimation of the broken down tasks - so basically you keep adding tasks to the sprint list until the sprint capacity is full. In your case, sprint capacity would be 2 devs * 8h/day * 10 days.
Don't worry if, in the beginning you will not be so sure on their estimates... given time you will start to get a real feeling of how much tasks should take without having a real IT background. Keep on asking all the questions you need to understand the details of their estimations. What needs to be modified, what are the implications, what are the risks, what areas are affected by this change and need to be tested, etc.. should be questions you usually ask.
Also, working closely with them in this manner will give you the advantage of controlling their work quite closely without falling in the micro-management pitfall.
Hope this helps.