Unfortunately, since you're the only engineer on the team, there was probably an unspoken assumption that you would also fill the role of an engineering manager

Unfortunately, since you're the only engineer on the team, there was probably an unspoken assumption that you would also fill the role of an engineering manager who, in a bigger company or team, would not just drive progress from the engineers, but also communicate that progress back up to the non-technical members of the leadership team in terms of the "why does this matter" aspect of whatever tasks you or your team is completing. That is NOT an easy thing to learn, often it's trial-and-error feeling out what language and method of communication is best received by the other internal stakeholders in the company. My entirely anecdotal experience has been that, when you first start at a new position like this where you are expected to communicate tough concepts to folks with no training in those concepts, it's often best to go straight to the high-level strategies and goals of the company/CEO/CTO/etc. Take those desired outcomes and map your work to them, putting on paper exactly how your work will enable those goals and coming up with some initial thoughts on how to quantify your progress toward meeting those (sometimes admittedly unquantifiable) strategies. If you then report regularly on those metrics, that goes a long way toward explaining the "so-what" of the tasks you're doing.