Software development manager and product manager with a strong background in agile methodologies and roots in UI experience and design. 10+ years of experience.
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.
I think you should go deep, but not with a certain technology. Think about it a bit differently and go deep in an area.
For example, as you put it, instead of being "the best SQL guy" work your way on being "The best Database guy". Instead of being "The best Javascript guy", go towards being "The best Frontend" guy.
Remember, technologies change fast, there will always be new platforms, new DB types (just think about Big Data and their adoption rate in the latest years). You will not be safe if you master a technology, but if you master a domain you will have deep knowledge on the subject and you will be quick(er) to adapt to any new technology coming your way.
Best of luck!
This may not be an answer that you can immediately apply, but I strongly recommend you to read The Four Steps to the Epiphany, written by Steve Blank.
It's maybe one of the best books I have read on this subject. It will take you through all the steps you need to take and it has a straight forward approach to it.
Here's the link: https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/0989200507