That's a really good question. Luckily the right answer, as all things in life, is as simple as pie. Don't track their work - pay attention to results.
Say you need an app that does features A, B and C for a specific audience of accountant nurses. You already know what features A, B and C should feel like as they are described in the initial requirements. So checking them out is simple - do they work as they are originally intended to?
Secondly, you have a deadline. Your product should hit the market, say, next Tuesday. Is all of the functionality released timely? Are you making it within the timeframe?
Thirdly, you have a budget. Do your best to stay within limits just like you usually would on any other non-technical project.
What I'm trying to say is that you shouldn't micromanage developers. You are to manage the project.
But, in case you really need some productivity metrics to set up as KPIs for your tech team you should:
Pay attention to the bug ratio found in QA.
Bugs per line of code is a nice metric.
Ability to deliver valid results in time.
Technical debt. Here's how you measure it: https://qarea.com/articles/3-outside-box-ways-measuring-technical-debt
There are tools that measure that stuff as well as code quality. Check them out here: https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
PS: Here are some great materials about how a SCRUM team should operate (and deffinetely consider the SCRUM approach for your next project: https://qarea.com/articles/game-scrum-who-who-and-what-do-next
My response will be more from a communication level. The problem many engineers face when they move into the role of CEO, is 1-they lack a well rounded business background and knowledge, 2-they often struggle with larger conceptual elements and strategy of running a business.
If you are the CEO, you have to find the balance between CEO who is part of the team, and CEO who reserves the right to terminate an employee who can not properly adhere to timelines. But also, part of hiring experienced engineers is that they know their abilities.
I came in to develop and build a company of engineers once. The CEO was an engineer turned CEO, and he failed miserably with communicating the larger needs of the company to his engineers. He pretended he had the skill set of a CEO, but he never even remotely got out of engineer mode. Often times he would lecture his engineers about deadlines. He liked to talk more than listen (not a trait of a leader). On the other hand I would pull the engineers aside and ask them what they needed.
There was far more buy in. They felt valued, and I saw their motivation and productivity increase dramatically. If you can convey the importance of deadlines to you and them, and illustrate that the deadlines benefit the company and through that the engineers because you value them and care about their careers, you will see increased productivity.
Have you asked your engineers why they come to work? What do they value about work. What is it that their families enjoy. Maybe it's a two week cruise they have never been on. Find the way to reward results. Maybe one of them has a dream project or product that aligns with your company somehow. As they finish the current projects, perhaps you can support them on their passion project.
You can apply all the software programs, project managers in the world. If you don't understand what moves your employees as human beings and professionals, you will continue to struggle to get results.
But if you have done this, and you have instituted weekly deliverables, and you find your engineers are not performing as they should, you have to be the CEO and with that role comes the difficult task of letting people know they must perform.