How do I deal with upper management's overfixation with frontend/aesthetic/visua...

Cutting the story very short, I got into the unlikely position of CTO in a small company just by sort of being the only developer at some point in time, but actually having no abilities nor experience in leadership or management.

This means I'm constantly acting as the buffer between upper management (CMO, CEO, COO) and the tech department, but also most of my time is to be dedicated to development.

Currently, we're about to finish what I consider the most important project ever done for the company (replacing all legacy systems, which solves a lot of issues by itself and unblocks many further improvements) which has spanned throughout a little more than a year.

The problem we've been carrying for some time is that upper management is overly fixated with improving the visuals, aesthetics, and frontend of our applications, which means these have been getting consistently prioritized over maintenance, security or performance concerns, which, on the other hand, have been given for granted like they should have never been concerns to begin with.

We're currently at a delicate point since this is a very important task that's going to wildly affect the company (which by the way, has been growing greatly for several years), but most of the work is on the backend, and thus we have nothing to show for it.

This means we're being consistently pressured to finish sooner and incentivized to cut corners as much as possible to meet some very arbitrary deadlines. I even have the belief that upper management might be thinking we're slacking off because we haven't shown any aesthetical changes, even though I'm consistently putting more than 100 hours a week into it.

This is really bringing myself and other team members to feel really burnt out.

The tipping point was the latest meeting where I was given a list of "very important issues that MUST be definitely fixed before release". This list is composed exclusively of aesthetical changes, minor translation changes, using different stock images, etc. At this point I just realized I can't let this go on for any longer, since I've had to cut corners throughout the development in stuff I considered important, however this banal stuff is somehow ESSENTIAL for the release.

I know that at this point there's little more to do than scheduling a meeting and discuss expose the situation exactly as I'm doing now, and even flat out refuse to perform these changes unless the deadline is extended. But I'm curious about what could have I done before to prevent reaching this point. Is there any way I can convince upper management that we're actually working and making progress even though we're not producing any sort of "visual" outcomes they could see?

Update: Thanks to everyone who commented. As always, in the process of reading answers and responding to comments, I realized that my framing of the issue was wrong. There have been definitive visual and revenue outcomes from our work, but they were dismissed by upper management for not having customer-facing impact. However, this just shows that priorities are wildly off, and the only way to solve it is to seriously educate them about the technological needs of the business.

I know this might not be the answer you're willing to hear read, but most of the time (if not always), pitching the product to a new customer or introducing changes/upgrades to existing customers involves a "high-level" meeting, where the primary focal point of discussion / presentation is the value-add, and not actual day-to-day functionalities of the product.

When someone is trying to sell a product (i.e., solving a problem) in a meeting, with a very limited time in hand (upper-level business meetings tend to be very short), they are likely competing with multiple other organizations/vendors offering similar functionality, and everyone need to make an "impact" that will help the customer decide "best among the equals". Usually, rather than a bullet-point list of features and functionalities, some sort of visuals, or dashboards, and ease-of-use, learning curve - these are usually more attractive and catchy, and provide a more immersive, emotional and dramatic experience to the storytelling.

In other words, the frontend (UI/UX/Aesthetics/Visuals) is the first and most exposed part of software products and solutions, and having a better one provides an edge over other competition solutions.

Now, coming to your specific question - I understand you are looking at things from a technical point of view and your viewpoints are absolutely valuable and should be honored, however it is also important to have a good representation of the features, functionalities and capabilities in an easy-to-understand and easy-to-demonstrable way. For example, we can either measure the performance of a system by

• Going to a console, keying in couple of system commands and see the raw stats on screen.
• Pointing your browser to a dashboard, showing graphs for value trends, integrated with colors for thresholds and alerts for out-of-rang values.

and in most of the cases, business people will choose the later approach.

I'm not denying the fact that the backend, or the actual working of the software is important, but with a poor representation, it's not going to get you a seat in the front row.

Navigating the challenges of being a CTO in a small company, especially with limited experience in management, can be daunting. Your situation is certainly complex, but there are some steps you can take to address these issues going forward:

1. Whenever you add / change / update a feature, plan a way to visualize the "impact" of the change - it need not always be a direct visual representation of the direct change, but as little as a visual comparison of the increase in efficiency, decrease in operational cost, increased ease of use, decreased response time - you get the idea.
2. Whenever a change is requested just for the aesthetics or cosmetic purpose, try to understand why the existing solution is not good enough, and next time, use that understanding to incorporate that viewpoint in the solution from the beginning.
3. Create a plan / standardize the UI/UX across the product (or the portfolio of solutions), and try to reuse the components as much as possible, so it serves the purpose as needed by the Sales / Marketing or the Product management team.

Hope these changes will help you to organize and plan your activities properly and you'll get out of the detrimental 100+ hour work-week.